Make task config only readable from task crate build script

[mkeeter]

Right now, dispatching cargo once per task is a reason why incremental rebuilds are slow. I would like to live in a world where we dispatch cargo once to build multiple (compatible†) tasks.

One issue with this plan: build scripts for library crates are free to read HUBRIS_TASK_CONFIG and react accordingly. In a world where multiple tasks are built in a single cargo invocation, there's no single HUBRIS_TASK_CONFIG to read.

The PR eliminates that behavior: build scripts that read HUBRIS_TASK_CONFIG must have a CARGO_PKG_NAME that matches the task crate name. In other words, only a task's build script may read the task config. Otherwise, the build_util::*task*config function will panic.

This is useful because it also works in the opposite direction: when this property is true, we can use CARGO_PKG_NAME to unambiguously‡ pick which task config to use.

---

It turns out that we almost had this property already! The one exception is the drv-stm32h7-spi-server-core crate, which had a build script that read the parent task configuration to pick which SPI peripheral to codegen. In this PR, I make that codegen the parent crate's responsibility; drv_stm32h7_spi_server_core::SpiServerCore::init now takes a configuration from the caller, instead of baking it into a global variable.

The build script for drv-stm32h7-spi-server-core is moved to a separate build-stm32h7-spi-server-core, so that all of the parent crates can invoke it themselves.

---

† "compatible" means that they enable the exact same set of features in their dependencies, to avoid feature unification surprises
‡ We will still be unable to simultaneously build multiple tasks that use the same crate, e.g. spi2 and spi3, but that's fine