build: build the firmware with CMake

[gmarull]

Replaces the waf firmware build with CMake, driven by Ninja.

./pbl configure --board asterix
./pbl build

What changes

The build model is the one waf had grown into, which was itself borrowed
from Zephyr, so the shape of a directory's build file is unchanged —
declare a library, give it sources, gate the optional pieces on Kconfig:

pbl_library()
pbl_library_sources(service.c)
pbl_library_sources_ifdef(CONFIG_MAG correction.c)

What the build does is unchanged too. Kconfig still resolves the board's
configuration into .config and autoconf.h; the resource pipeline, the
generated tables and headers, the linker script hooks, the C library
selection and the image and bundling steps all keep their behaviour.

The generators the build shells out to move from waf task classes to plain
command line tools under tools/cmake/, and the helpers that were never
waf-specific (board parsing, the pblboot header, SLE) move out of
tools/waf/ next to the rest of the tooling.

waf stays for what it still builds: the unit tests, out of their own build
directory, and the SDK packaging (./pbl waf sdk).

docs/development/build_system.md is rewritten around the new API.

Verification

• qemu_flint: byte-identical system resources, and an ELF with the same
  symbols at the same sizes, differing only in padding inside .text.
• asterix: identical .text / .bss / .log_strings sizes and an
  identical symbol table.
• Firmware, PRF, QEMU and SDK-shell workflows all build in CI.

Why CMake and not Meson

A full Meson port was written and benchmarked against this branch before
settling. Same board, same machine, ccache off:

	CMake	Meson
configure	1.4 s	4.3 s
clean build	48.8 s	49.7 s
null build	0.30 s	0.31 s
rebuild one file	1.9 s	3.3 s
reconfigure	1.0 s	3.9 s

Both emit Ninja, so the build itself is a wash. The gaps are all
configure-time, and the deciding factor was expressiveness: Meson has no
user-defined functions, so pbl_library() becomes a dict literal the root
assembles later, which added ~950 lines to the per-directory files
contributors actually touch. It also has no per-source compile flags
(__FILE_NAME_LEGACY__ needed a compiler wrapper, which rules out
ccache), no globbing and no CONFIGURE_DEPENDS, cannot read a file out of
the build directory, cannot name a subdirectory in a custom_target
output, and has one flat variable scope shared across subdir().

[gmarull]

Build performance, measured against waf

I profiled the build and pushed three commits on top of the migration. All
numbers below are asterix, ccache off, on the same 8-core machine in one
sitting, so the three columns are comparable to each other (the machine was
busier than when the numbers in the PR description were taken, so the
absolute values are higher — read the columns against each other, not
against the description).

	waf (main)	CMake (before)	CMake (now)
configure	1.5 s	2.7 s	2.3 s
clean build	99.1 s	94.9 s	68.3 s
no-op build	2.6 s	0.7 s	0.5 s
rebuild one file	3.3 s	3.8 s	1.6 s
reconfigure	0.8 s	1.7 s	1.4 s

Against waf that is 31 % off a clean build, 5× off a no-op and 2× off the
inner loop; configure is the one step that is slower, by about 0.8 s, which
is CMake's compiler detection and find_package(Python3).

The firmware is unchanged by all three commits: same pebbleos.bin, same
loadable sections, same symbols at the same addresses. The ELF drops from
24 MB to 17 MB and the ninja graph from 2892 to 2351 edges.

Where the time was going

Clean build: 63 % compiling firmware, 18 % generating resources, 15 %
compiling third-party code, the rest linking and archiving. Inside a
compile, 57 % is the preprocessor — and that is header content, not the
search path: passing only the include directories a file actually uses
(a median of 7 of the 96 it is given) makes no measurable difference, and
-O0 is not faster than -Os. No-op build: 78 % of it was one rule.

What the three commits do

1. build: generate resources in batches — every one of the 581
   resources was its own Python process, and 77 ms of the ~100 ms each took
   was the interpreter and its imports. 120 resources cost 9.8 s of CPU one
   process at a time and 0.5 s in a single process. They are now grouped by
   type and built 16 at a time: 40 rules instead of 581, ~45 s of CPU off a
   clean build.
2. build: make the macro debug info and the linker map opt-in — -g3
   costs ~7 % of the compile and a 3.4 MB .debug_macro section that also
   slows the link; -Wl,-Map with --cref writes tens of megabytes and is
   about a fifth of the link. Both are Kconfig symbols now
   (CONFIG_DEBUG_INFO_MACROS, CONFIG_LINKER_MAP), off by default. Turn
   the second one on before running
   tools/analyze_fw_static_memory_usage.py.
3. tools: skip submodules in the firmware version's dirty check — the
   version header is regenerated on every build, and git describe --dirty
   was 0.24 s of the 0.31 s that took, all of it walking into the
   submodules. The dirty flag is now a separate check that ignores their
   working trees (a submodule moved to another commit still counts).

Left on the table

The remaining 63 % is header fan-out — 57 % of every compile is the
preprocessor working through PebbleOS's headers. That is a source refactor
rather than a build-system change, so it is not in this PR, but a histogram
over ninja -t deps would name the worst offenders. Splitting the global
include path per library would also shrink build.ninja, 75 % of which is
-I flags, though it buys no compile time.