Retire submodules

[lxsaah]

Retires two of the three _external/ submodules and cuts the [patch.crates-io]
block from five entries to three.

Why

aimdb-knx-connector and aimdb-mqtt-connector depended on vendored forks of
knx-pico and mountain-mqtt through [patch.crates-io]. That works inside this
workspace and nowhere else: a patch is workspace-local and is stripped from a
published manifest, so any downstream consumer resolved to the upstream crate
instead. Both forks also carried the same name and version as a live upstream
release, so there was no version number that could mean "the fork".

The consequences differed by crate, and one of them was not a latent bug:

Fork	If a dependant resolved upstream
knx-pico 0.3.0	compiles, then panics on an npdu_length=1 telegram
mountain-mqtt 0.2.0	does not compile — the fork adds ConnectionSettings::authenticated, called by embassy_client.rs

Git dependencies do not fix this either: cargo refuses to package a git dependency
with no version, and if you add one it packages happily while deleting the git
specification.

What changed

The forks are now published under names we own and are consumed from crates.io:

• aimdb-knx-pico 0.3.1
• aimdb-mountain-mqtt 0.2.1
• aimdb-mountain-mqtt-embassy 0.2.1

Each is declared with a package alias, so no Rust source changed:

knx-pico = { package = "aimdb-knx-pico", version = "0.3.1", default-features = false }

The left-hand key is unchanged, which keeps use knx_pico::… and the knx-pico/*
feature references working. With no path alongside, Cargo.lock now records
source = "registry+…crates.io-index" — this workspace compiles the same artifact a
consumer gets, which was the entire point.

_external/knx-pico and _external/mountain-mqtt are deregistered. The fork
checkouts live beside the other repos in aimdb-dev.code-workspace and are only
needed when working on a fork.

Embassy: reduced, not retired

_external/embassy stays, and the patch block keeps three entries:

embassy-sync = { path = "./_external/embassy/embassy-sync" }
embassy-net-driver-channel = { path = "./_external/embassy/embassy-net-driver-channel" }
embassy-net-driver = { path = "./_external/embassy/embassy-net-driver" }

aimdb-embassy-adapter/src/buffer.rs calls Subscriber::poll_next_message and
Receiver::poll_changed, which are merged upstream but absent from the released
embassy-sync 0.8.0. The two driver crates follow because published
embassy-net-driver-channel 0.4.0 calls a pre-guard zerocopy_channel API the patched
embassy-sync no longer has, and its driver trait must be the same instance
embassy-net sees.

Everything else — embassy-executor, embassy-time, embassy-net,
embassy-futures, embassy-stm32 — now resolves from crates.io at the declared
versions.

This leaves a known gap. aimdb-embassy-adapter cannot be honestly published until
an Embassy release carries those APIs, and the failure is quiet: the crate is
default = ["alloc"], so cargo publish's verify build never reaches the affected
code, and make publish passes --no-verify for it anyway. Tracked as a release gate,
not fixed here. When the release lands, the patch block and the submodule go together.

Notes for reviewers

• Submodules are still required. cargo resolves one graph per workspace, so a
  missing _external/embassy breaks every member, not just the embassy ones. CI needs
  submodules: recursive.
• Fork changes are now a three-step process: bump the fork's version, publish it,
  then bump the requirement in the consuming connector. The middle step is easy to skip,
  because nothing local breaks if you do.
• No source files changed — this is manifests, Cargo.lock and submodule registration.

Verified

make check locally, plus targeted builds after the submodule removal: the KNX
connector on tokio, the MQTT connector with embassy-runtime cross-compiled to
thumbv7em-none-eabihf, and the sibling aimdb-weather-mesh workspace, which consumes
these connectors by path and is not covered by this repo's CI.