ci_cortex_m duplicates the GCC check for four cores, and can only be retired if stage 5 grows a second shape

[fdesbiens]

.github/workflows/ci_cortex_m.yml was repaired in #653 — it had been failing in seven seconds on every run since at least June, dying at Prepare all required actions because it used actions/cache@v1, which GitHub auto-fails. It now builds Cortex-M0/M3/M4/M7 with GCC through CMake.

With gcc_check in place (#675) the case for keeping a second, much narrower GCC workflow is weaker than it was. Deleting it was proposed and declined with a reason, and this issue records that reason so the question can be settled properly rather than re-argued.

Why it was kept

ci_cortex_m is the only thing that builds the M-profile ports through CMake. check_gcc.sh covers those ports' sources and their script-driven example builds, but its CMake stage covers cortex_r52 only.

Why folding it in is not a like-for-like move

The two do different things, and that is the crux:

• check_gcc.sh's CMake stage builds images, discovered from a graph of .elf targets, and asserts a count.
• the Cortex-M CMake path builds the library with the default target, and produces no image.

So absorbing it needs a second shape in stage 5, not four more entries in CMAKE_EXAMPLE_CORES. That is real code in a script that is currently uniform, and it is the reason this was not simply done.

The decision to make

Either:

• fold it in, accepting a second shape in stage 5, and delete ci_cortex_m.yml — one fewer workflow, one fewer set of pins to keep current, one fewer thing to rot unnoticed for three months; or
• keep it, and accept a duplicate GCC workflow in every pull request's checks list.

Worth doing only if the duplicate check is judged to cost more than the code. Note that whichever way it goes, ci_cortex_m.yml still pins lukka/get-cmake@v3.19.1, a CMake from 2020, which is worth looking at if it stays.

Follows from #653 and #675.