Add Zephyr RTOS (Generic) platform support

[npitre]

This PR adds XNNPACK build support for the Zephyr RTOS. Zephyr sets
CMAKE_SYSTEM_NAME to "Generic" (per CMake convention for baremetal/
RTOS cross-compilation targets), which XNNPACK's CMakeLists.txt
currently rejects as "Unrecognized".

Changes:

• CMakeLists.txt: recognise "Generic" as a valid platform.

• src/xnnpack/common.h: guard the default XNN_HAS_MMAP definition
  with #ifndef so platforms without mmap (including Zephyr baremetal)
  can set XNN_HAS_MMAP=0 at the command line.

• src/log.c: add Zephyr to the STDERR_FILENO/STDOUT_FILENO fallback
  path (matches the existing Hexagon pattern — on both platforms
  those file descriptors aren't meaningful for log output).

Motivation: this is part of enabling ExecuTorch + XNNPACK inference
on Arm Cortex-A class cores running Zephyr (specifically the Arm
Corstone-1000 Edge-AI platform with Cortex-A320 + Ethos-U85).

Tested: XNNPACK builds and runs a CPU-only add model via the
ExecuTorch XNNPACK backend on the Corstone-1000-A320 FVP, selecting
NEON microkernels (xnn_f32_vadd_ukernel__neon_u8).

Follow-up: a small follow-up PR will add a Cortex-A320 case to
cpuinfo_to_xnn_uarch() in src/configs/hardware-config.c. That
change depends on cpuinfo adding the cpuinfo_uarch_cortex_a320
enum first, which is tracked in pytorch/cpuinfo#379.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.