refactor: extract shared CMSIS to libs/3rdparty/cmsis

[nhuvaoanh123]

Summary

Moves CMSIS 6.1.0 headers from `platforms/s32k1xx/bsp/bspMcu/include/3rdparty/cmsis/` to `libs/3rdparty/cmsis/` so that future Cortex-M platforms can share the same CMSIS core without duplication.

This is the preparatory refactor referenced in PR #413 discussion and the strategy doc under `docs/stm32-pr-strategy.md` on the STM32 series branch.

Changes

• Move 9 CMSIS files to `libs/3rdparty/cmsis/` (6 byte-identical, 3 with trivial Doxygen comment-style diffs that are preserved as-is)
• Add `libs/3rdparty/cmsis/module.spec` following the `libs/3rdparty/googletest/module.spec` pattern (unit_test: false, format_check: false, oss: true)
• Update `platforms/s32k1xx/bsp/bspMcu/CMakeLists.txt` to add the new CMSIS paths to `target_include_directories`
• Update `platforms/s32k1xx/bsp/bspMcu/include/mcu/mcu.h`: change hardcoded `#include "3rdparty/cmsis/core_cm4.h"` to bare `#include "core_cm4.h"` (resolved via the new include path)
• Remove CMSIS entries from `platforms/s32k1xx/bsp/bspMcu/module.spec` exclude globs (files are no longer under this module)
• Consolidate `NOTICE.md`: single CMSIS entry pointing to `libs/3rdparty/cmsis/LICENSE`

Non-goals

• No functional changes
• No STM32 code
• No new CMake targets

Test plan

• s32k148 FreeRTOS cross-compile succeeds locally (`cmake --preset s32k148-freertos-gcc && cmake --build --preset s32k148-freertos-gcc`) — `app.referenceApp.elf` produced (231 KB text + 100 KB BSS, fits well within S32K148 flash)
• CI: `tests-s32k1xx-debug` host unit tests pass (awaiting CI — blocked locally by pre-existing mingw64 toolchain issue in `libs/bsw/util`, unrelated to this change)
• CI: s32k148 ThreadX cross-compile succeeds
• CI: clang-tidy passes

🤖 Generated with Claude Code

[rolandreichweinbmw]

Libs under libs/3rdparty mostly have .riminfo files available to be able to check consistency with upstream.

Can you provide that one also?

[nhuvaoanh123]

Hi @rolandreichweinbmw — quick question before producing the .riminfo. The CMSIS files in this PR were relocated from platforms/s32k1xx/bsp/bspMcu/include/3rdparty/cmsis/, not freshly imported via RIM, so there's no original RIM provenance to preserve.

Two options:

• (a) Run RIM retroactively against ARM-software/CMSIS_6 v6.1.0 — would require locating the RIM CLI on our side and confirming whether the vendored copy is vanilla v6.1.0 or carries local patches (any divergence would need to land in the ignores field).
• (b) A stub .riminfo pointing at the upstream URL/tag without RIM-validated checksum, acknowledging this is a relocation rather than a fresh import.

Which would you prefer?

Also pushed 473d0713 to clear the cmake-format treefmt failure.

[rolandreichweinbmw]

Hi @rolandreichweinbmw — quick question before producing the .riminfo. The CMSIS files in this PR were relocated from platforms/s32k1xx/bsp/bspMcu/include/3rdparty/cmsis/, not freshly imported via RIM, so there's no original RIM provenance to preserve.

Two options:

• (a) Run RIM retroactively against ARM-software/CMSIS_6 v6.1.0 — would require locating the RIM CLI on our side and confirming whether the vendored copy is vanilla v6.1.0 or carries local patches (any divergence would need to land in the ignores field).
• (b) A stub .riminfo pointing at the upstream URL/tag without RIM-validated checksum, acknowledging this is a relocation rather than a fresh import.

Which would you prefer?

Also pushed 473d0713 to clear the cmake-format treefmt failure.

I propose (a). Checksumming and providing traceability to a certain upstream version/commit is the whole point of RIM.