science/py-tensorflow: fix and enable the build on powerpc64le

Most of the architecture gates that had to be fixed failed the same way:
the port's cc_toolchain_config hardcodes cpu = "freebsd", which names the
OS and not the CPU, so bazel config_settings written as
values = {"cpu": ...} cannot tell FreeBSD architectures apart. The C
preprocessor still takes the correct powerpc path (it sees PPC64), so
bazel selected x86 sources while the compiler compiled powerpc ones.

• files/freebsd/BUILD: the FreeBSD cc toolchain was declared exec/target_compatible_with @platformscpu:x86_64, so on powerpc64le it never resolved and bazel fell back to the auto-detected toolchain, whose empty cxx_builtin_include_directories made it reject the numpy -isystem copt for every compile. Constrain on @platformsos:freebsd only, as the python_cc_toolchain in the same file already does.

• Makefile: clang rejects -march= on powerpc, and -mcpu=native is silently ignored there, so use -mcpu with a power8 baseline that CPUTYPE can override. Do not auto-detect the builder's CPU: the package builder may be newer than the target baseline.

• cpuinfo, XNNPACK and highwayhash: key the architecture config_settings on @platforms//cpu:* constraint_values instead of the cpu string. Without this XNNPACK compiled amd64 AVX-512 assembly and microkernels, and highwayhash included hh_vsx.h while bazel had selected hh_avx2/hh_sse41.

• XNNPACK: disable assembly on powerpc64le, and detect VSX using FreeBSD's elf_aux_info() with the PPC_FEATURE_* constants from <machine/cpu.h>. FreeBSD has no getauxval(); its absence was only an implicit-declaration warning that would have become a link error.

• XLA: builtin_fp16.h uses uint16_t in its fallback without including <cstdint>, and vector_ops.h/eigen_unary.cc use _Float16 behind a guard that only tests ext_vector_type. clang provides those attributes on powerpc but not _Float16, so also require FLT16_MANT_DIG.

• Makefile: link with -Wl,-z,undefs on powerpc64le. libtensorflow_framework is linked with -z defs, but LLVM's Program.cpp and tsl's subprocess.cc reference environ, which on FreeBSD lives in crt1.o rather than in libc.so. On powerpc64 its address is taken through a TOC entry that survives --gc-sections, so the link fails where it does not on amd64.

The XNNPACK and XLA changes are carried here only until TensorFlow picks
up revisions containing them; both have since been merged upstream:

https://github.com/google/XNNPACK/pull/11114 (merged 2026-09-03)
https://github.com/openxla/xla/pull/48240 (merged
2026-09-02 as openxla/xla commit 927b467078fd)

The cpuinfo and highwayhash problems are already fixed in newer upstream
revisions than the ones TensorFlow 2.21.0 pins, so those two hunks can be
dropped when the vendored copies are updated.

Tested on powerpc64le: py312-tensorflow-2.21.0_3 builds in 4h11m with a
clean pkg-plist. Also tested on amd64, which is unaffected: every hunk is
either ARCH-gated, inside #if XNN_ARCH_PPC64, or a constraint_values
addition that still matches on x86_64.