sbom: generate SBOMs from every wolfBoot build system

[sameehj]

Description

wolfBoot ships as source. Users build it in many ways. Each user needs an
SBOM for the build that the user makes. This PR makes wolfBoot produce a
CycloneDX 1.6 and SPDX 2.3 SBOM from every build system, and it makes the
SBOM reproducible.

One engine does the work. Each build system gives the engine two inputs:
the compiled source list and the build configuration. The engine captures
the configuration with the host compiler, so the SBOM is the same for GCC,
Clang, LLVM, IAR, armcl, CCRX, and XC32.

What is new

• A shared driver: tools/scripts/wolfboot-sbom.sh.
• Front ends for each build system:
  • Make and arch.mk and vendor SDKs: make sbom.
  • CMake and the Pico SDK: cmake --build --target sbom.
  • IAR Embedded Workbench: ide-sbom/iar_sbom.py.
  • Any IDE with a compilation database: ide-sbom/compdb_sbom.py.
  • TI CCS, MPLAB X, Renesas, Xilinx: ide-sbom/route_through_sbom.sh.
  • Per-HAL component: make sbom-hal.
  • Zephyr module: ide-sbom/zephyr_sbom.py.
• A validator: ide-sbom/validate_sbom.py.
• A CI canary: .github/workflows/test-sbom.yml.
• Documentation: docs/SBOM.md and docs/SBOM-WOLFGLASS.md.

Reproducibility fix

The driver captures build macros with the host compiler. Some macros hold
an absolute host path. For example, arch.mk passes
-DPICO_SDK_PATH=$(PICO_SDK_PATH). Before this change, the path entered
the SBOM. The SBOM was then different on each machine, and it leaked the
local file system.

The driver now redacts each absolute path in the captured macros. It keeps
the macro name, so the configuration record stays complete. The CI canary
asserts that no path leaks and that the macro name stays. Use --no-scrub
for debug only.

Toolchain support

The SBOM content does not depend on the cross-compiler. The config uses
the host compiler. The composition is a source list. So Clang, LLVM,
Renesas CCRX, TI armcl, and IAR all give the same SBOM. A new toolchain
needs no work. A new IDE that emits a compilation database needs no work.

Relation to wolfGlass

The tools are product-neutral. They are self-contained in wolfBoot on
purpose. They are the reference implementation of the shared SBOM layer
for every wolfSSL product (wolfSSL, wolfHSM, and others). docs/ SBOM-WOLFGLASS.md gives the file-by-file migration map and the list of
changes that wolfGlass must cover. No wolfBoot logic changes when the
tools move.

Prerequisite

The tools need gen-sbom from wolfSSL (lib/wolfssl/scripts/gen-sbom).
If the pinned submodule does not carry it, pass a path with GEN_SBOM=...
or the --gen-sbom option. The CI canary fetches it from wolfSSL master
as a fallback.

Testing

• make sbom TARGET=sim produces a valid SBOM. The validator passes.
• make sbom-hal TARGET=sim produces a valid per-HAL SBOM.
• cmake --build <dir> --target sbom produces a valid SBOM.
• The IAR, compdb, and Zephyr extractors produce valid SBOMs.
• The scrub check confirms that no absolute path enters the SBOM and that
  the macro name stays.

Notes

• wolfBoot embeds wolfCrypt sources. The SBOM lists these as wolfBoot
  sources, not as a separate component.
• A vendor SDK build lists only the source files on disk.
• The driver is a POSIX shell script. On Windows, run it in WSL, MSYS, or
  Git Bash. As an alternative, use compdb_sbom.py.

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #830

No scan targets match the changed files in this PR. Review skipped.