Investigate MQTT 5.0 support

[sidick]

Investigate whether midge should eventually support MQTT 5.0 alongside (or instead of) 3.1.1.

Why it might be worth it:

• Topic aliases — a real bandwidth win over repeating full topic strings on every PUBLISH, relevant given the target hardware/network constraints.
• Reason codes + user properties — better diagnostics than today's bare CONNACK/SUBACK return codes (see src/core/mqtt_client.h's mqtt_client_connack_code()).
• Session/message expiry, request-response pattern, shared subscriptions.

Why it might not be worth it (yet):

• Every relevant broker (Mosquitto, EMQX) and Home Assistant still fully support 3.1.1 — nothing is currently blocked by staying on it.
• MQTT 5 packets carry variable-length Properties on nearly every packet type, a materially bigger lift for the portable codec (src/core/mqtt_packet.c) than the current fixed-layout 3.1.1 encode/decode.
• QoS 2 is already out of scope by deliberate choice (docs/PROTOCOL.md) — worth weighing MQTT 5 complexity against that same minimalism bar.

Scope of the investigation: whether to support 5.0 as a protocol-version negotiation on the same core, a separate opt-in codec path, or not at all; how much of src/core/mqtt_packet.c/mqtt_client.c could be shared vs. needs to fork; whether any target use case (Home Assistant discovery, the Phase 4 dashboard) actually needs a 5.0-only feature.

Not scheduled against any current phase in docs/ARCHITECTURE.md — investigate and decide before committing it to the roadmap.