Add ControlCoordinator extension sideloading for external robot packages

Problem

External robot packages need a supported way to register ControlCoordinator hardware adapter names and control task types without placing files inside the DimOS source tree. Without this, an outside package can define a blueprint but still cannot use HardwareComponent(adapter_type=...) or TaskConfig(type=...) for custom hardware/control unless DimOS itself is modified.

Solution

Add a public dimos.control.extensions facade for explicit extension registration:

• register_hardware_adapter(HardwareType, adapter_type, factory) dispatches to the existing manipulator, base, or whole-body adapter registry.
• register_control_task(task_type, factory_path) registers lazy control task factories without importing the target module at registration time.
• Hardware and task registries reject conflicting duplicate registrations while keeping exact same mapping re-registration idempotent.
• Add docs and a runnable no-hardware external package example that logs registration, adapter construction, task creation, task ticks, and adapter writes.

This keeps blueprint usage unchanged: external packages register before coordinator construction, then use normal HardwareComponent and TaskConfig names.

PR

dimensionalOS/dimos#2547

Manual QA

uv run python examples/external_control_extension/demo_external_control.py

Expected output includes [external_test_robot] logs for registering the adapter/task, constructing and connecting the adapter, creating/ticking the task, and writing velocities through the external adapter.

Synced from DIM-1031 by che

Start with examples/external_control_extension/demo_external_control.py and run the documented uv command. Check that the external example demonstrates registration, adapter construction and connection, task creation and ticks, and adapter writes, with the expected [external_test_robot] logs. Done means the public extension flow works without modifying the DimOS source tree.