Unify WAMR_BUILD_TARGET auto-detection across all CMake build files

[brainrom]

Is your feature request related to a problem? Please describe.

The auto-detection of WAMR_BUILD_TARGET based on the CPU architecture is duplicated across many CMake files in the project with at least 3 different patterns, each supporting a slightly different subset of architectures. ARM auto-detection, which is the reason why I started to investigate, is missing — scripts detect AARCH64 but not ARM or THUMB. Some files use CMAKE_SYSTEM_PROCESSOR, others use CMAKE_HOST_SYSTEM_PROCESSOR. Some files detect AMD_64, MIPS, or XTENSA; most do not. This makes the build system inconsistent and harder to maintain.

Describe the solution you'd like

A single, centralized CMake module (e.g. build-scripts/detect_target.cmake) that handles all architecture auto-detection in one place, with the following behavior:

1. Only runs when WAMR_BUILD_TARGET is not already defined (preserving override).
2. Checks CMAKE_SYSTEM_PROCESSOR and (if empty) falls back to CMAKE_HOST_SYSTEM_PROCESSOR to support both cross-compilation and native builds.
3. Detects all targets currently used across the project:
   • AARCH64 — arm64 / aarch64
   • ARM / THUMB — arm* / thumb* (with or without VFP variants)
   • RISCV64 / RISCV32 — riscv64 / riscv32
   • MIPS — mips*
   • XTENSA — xtensa*
   • X86_32 — i686 / x86 / i386
   • X86_64 — x86_64
   • AMD_64 — amd64
4. Normalizes via string(TOUPPER ...).
5. Falls back to CMAKE_SIZEOF_VOID_P (→ X86_64 on 64-bit, X86_32 on 32-bit).
6. Emits SEND_ERROR / FATAL_ERROR on unknown architectures.
7. Prints message(STATUS "WAMR_BUILD_TARGET: ${WAMR_BUILD_TARGET}").

All files that currently contain an if (NOT DEFINED WAMR_BUILD_TARGET) block would be replaced by a single include(build-scripts/detect_target) line. Per-target logic like WAMR_BUILD_SIMD (currently set inline in product-mini/platforms/linux/CMakeLists.txt and samples/wasm-c-api/CMakeLists.txt) would stay in those files, right after the include.

Files that hardcode a single target (e.g. zephyr/simple/CMakeLists.txt → X86_32, riot/CMakeLists.txt → X86_32, android/CMakeLists.txt) would remain unchanged, as they represent constrained platforms where auto-detection is not meaningful.

Describe alternatives you've considered

1. Leave as-is — auto-detection remains fragmented, and new architectures or bugfixes must be patched in dozens of files.
2. Add only ARM detection — solves the immediate ARM problem but does not address the broader duplication and inconsistency (missing MIPS, XTENSA, THUMB, AMD_64 in many files).
3. Use a function/macro instead of a standalone module — functionally equivalent, but a module is simpler to include and does not rely on function visibility order.

Additional context

Files and their current auto-detection patterns (abbreviated):

Pattern	Key difference	Files using it
CMAKE_SYSTEM_PROCESSOR — detects AARCH64, RISCV64, X86_64, X86_32	No ARM, THUMB, MIPS, XTENSA	Root CMakeLists.txt, product-mini platforms, samples, test files
Same + WAMR_BUILD_SIMD	Adds SIMD default for AARCH64/X86_64	product-mini/platforms/linux, samples/wasm-c-api
CMAKE_HOST_SYSTEM_PROCESSOR — detects 9 targets	Uses CMAKE_HOST_*, adds ARM_32/MIPS_32/XTENSA_32, does TOUPPER	wamr-compiler/CMakeLists.txt
CMAKE_SIZEOF_VOID_P only	No arch-specific detection at all	product-mini/platforms/windows, product-mini/platforms/vxworks, tests/unit/unit_common.cmake

Questions

• Should wamr-compiler always use CMAKE_HOST_SYSTEM_PROCESSOR, because it's host-only tool and shouldn't be built in cross-compilation scenario?
• Naming convention: use ARM or ARM_32?
• Should WAMR_BUILD_SIMD defaults (for AARCH64/X86_64) be moved into the common module? (It could be a separate feature flag.)
• How to handle the _VFP and _LP64D / _LP64 / _ILP32 / _ILP32D / _ILP32F ABI suffixes (ARM and RISC-V)? Should the detector try to auto-detect ABI from CMAKE_SYSTEM_PROCESSOR, or use most compatible ABI?