Add dmod-dev Debian SDK with existing CMake profiles and asset support

[JaxCalder]

Installing the host-tools package alone does not provide the files needed to build modules. This adds dmod-dev_<version>_all.deb, depending on the matching dmod package, CMake and build-essential. After installing both packages, consumers can build modules without a DMOD checkout:

cmake_minimum_required(VERSION 3.18)
find_package(dmod 1.0 CONFIG REQUIRED)
project(my_module LANGUAGES C CXX)
dmod_add_library(my_module "0.1" src/my_module.c)

DMOD_TOOLS_NAME and custom DMOD_TOOLS remain supported. Put find_package before project when selecting a profile so the compiler and original profile flags are set before language initialization. The SDK installs the original configuration profiles unchanged; it also supports a standard CMake toolchain file.

The package contains headers, relocatable CMake configuration, shared module-building functions, linker scripts, templates and runtime sources compiled with the consumer's compiler. Generated files stay in the consumer build directory. DMOD_BUILD_DEB=ON produces both packages. Documentation covers installation, FetchContent migration, custom prefixes and cross compilation. The SDK supports MODULE mode; SYSTEM/firmware builds and Make integration continue using the source checkout.

Based on develop at fbf6c90, including the latest view/image/font conversion support. The SDK uses those same CMake functions, including DMOD_ASSETS_PATHS, the backward-compatible DMOD_FIXTURES_PATHS alias, font sizes and tracking. Existing source/FetchContent/Make clients need no changes. Shared Makefile generation is disabled only by the installed SDK; checkout builds keep their existing behavior.

Validation:

• The complete existing CI passes: CMake and Make builds, loader/integration tests and external-module builds with both build systems.
• Debian CI passes with examples enabled and disabled: package contents/dependencies, APT installation/removal and host tools smoke tests.
• Installed-SDK tests pass with the checkout hidden, the SDK and consumer source read-only, and external networking disabled. They build/run a library, application and test module, compressed modules, and an independent dmod_link_modules consumer using a loopback test registry.
• CI passes for native arch/x86_64, the original Cortex-M7 profile and a separate generic ARM toolchain file. Local builds pass with original AArch64/Cortex-A53, ARM/Cortex-A53, Cortex-M4, Cortex-M7 and Xtensa/ESP32-S3 profiles; native AArch64 modules also run successfully. Cross builds validate compilation, not hardware execution.
• Real todmv, todmvi and todmvf converters pass in native and cross SDK builds: view/image/font outputs, multiple font sizes and tracking, ZIP package contents, incremental builds, and identical output using the legacy assets alias.
• An unmodified dm_sw_ring checkout builds through the existing FetchContent flow; its 12 tests pass. The legacy external Make application builds and runs. Configuration profiles and the legacy Make integration files are unchanged from develop.
• Additional checks cover relocated discovery, repeated find_package, disabled FastLZ, isolation of unrelated targets and invalid SDK configurations.

Known baseline limitation: the additional Make/AArch64-profile check exposes a quoting error in DMOD_ARCH. The same error reproduces on unmodified develop; this PR does not change those Makefiles or profiles.