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?

[jeevan6996]

I am interested in working on this. I checked the current open PRs for the issue number, WAMR_BUILD_TARGET, and a centralized target-detection module and did not find an implementation in progress.

Before changing the CMake entry points, I would like to confirm three scope details that affect compatibility:

1. Should wamr-compiler remain explicitly host-based? My preference is for the shared module to accept an optional processor input, defaulting to CMAKE_SYSTEM_PROCESSOR and then CMAKE_HOST_SYSTEM_PROCESSOR, while wamr-compiler explicitly supplies the host processor.
2. For values such as armv7 and thumbv7, should detection preserve the suffix as ARMV7 / THUMBV7, or normalize to the generic ARM / THUMB targets? Preserving the suffix appears consistent with the existing ARM.* and THUMB.* handling, but I do not want to infer ABI/VFP suffixes.
3. Should the size-only Windows and VxWorks detection blocks also use the common module? On Windows, recognizing amd64 as AMD_64 instead of falling through to X86_64 would be a visible behavior change even though both targets are supported.

I would also add a cmake -P test matrix for explicit override preservation, system/host fallback, each supported architecture family, pointer-size fallback, and the unsupported-architecture failure path. Hardcoded constrained-platform targets would remain unchanged.