Plugin configs (PLUGIN_REGISTRY) + ROS2 clock/gantry/odometry plugins

[juan-g-bonilla]

Builds on the lifecycle hook registry (base branch #158): the step loop emits phase events, and behavior attaches as callbacks. Core features (video recording, simulator bridge, virtual gantry) already run this way. This PR lets config/CLI attach the same kind of behavior without subclassing a backend, and ships the ROS2 example plugins.

What this adds

• A PluginConfig family (PLUGIN_REGISTRY, group holosoma.config.plugin) selectable as the dynamic-dict CLI field plugin.<key>:<preset>.
• A plugin is any class constructed as cls(cfg, simulator) that registers hooks on simulator.hooks in __init__ — duck-typed, no base class. It pairs with a PluginConfig whose get_cls() returns the runtime class. Same registry the core features use.
• Plugins are instantiated in BaseSimulator.__init__ (from FullSimConfig.plugin), so their hooks are registered before the loop emits any phase.
• Threaded through both entry points: RunSimConfig.plugin (sim2sim) and ExperimentConfig.plugin → base_task → FullSimConfig (training).
• Shipped presets: none (no-op), clock_publish + gantry_control (ROS2), and odometry — a self-sourced (non-camera) egress plugin that reads robot_root_states each control step and publishes nav_msgs/Odometry.

Why: one mechanism for step-loop side effects, core and custom alike — added logging, ROS2 bridges, teleop, egress, etc. become config presets (packaged entry point or --import-file) instead of loop forks.

API changes

• New field FullSimConfig.plugin: dict[str, PluginConfig] (default {}), plus registry-bound RunSimConfig.plugin and ExperimentConfig.plugin (and EnvConfig.plugin, threaded through get_tyro_env_config). Additive — existing configs unaffected.
• New public PluginConfig ABC (holosoma.config_types.plugin): subclass with your knobs as dataclass fields + implement get_cls(). Also NoOpPluginConfig, ClockPublishPluginConfig, GantryControlPluginConfig, ROS2OdometryPluginConfig.
• New entry-point group holosoma.config.plugin for packaged plugin presets.
• New extra holosoma[ros2] — opt-in marker for the ROS2 plugins (install rclpy from your ROS2 distro / RoboStack; the impls import it lazily so core stays importable without ROS).

Behavior changes

• None by default. The plugin field is empty unless you select plugins, so no existing run changes.
• When selected, a plugin's hooks fire at lifecycle phases (from the base branch): FRAME_BEGIN, PRE_STEP, POST_STEP, FRAME_END (periodic), EPISODE_START / EPISODE_END, CLOSE (once, reverse order).
• Rate fields accept an int decimation or a frequency string ("100Hz", ">100Hz", "<100Hz"), resolved against the phase's base rate; the registry sub-samples natively.

Usage

# ROS2: publish /clock at 100 Hz + drive the gantry over three topics
python -m holosoma.run_sim plugin.clk:clock_publish --plugin.clk.publish-every=100Hz plugin.g:gantry_control

# ROS2 odometry: publish the robot base pose/velocity as nav_msgs/Odometry
python -m holosoma.run_sim plugin.odom:odometry --plugin.odom.topic=/odom

Write-your-own (config + duck-typed class), phases, and cadence are documented in docs/writing-extensions.md (Plugins section).

---

Stacked on #158 (lifecycle hook system). Review after / alongside it; the diff here is the plugin family only.

[samuelgundry]

It's great to have examples that demonstrate the power of the hook-plugin system. Per comments below, I'll sync first with you and brain storm whether we want refinements now or deferred.

[samuelgundry]

I really dislike single config_types/hook.py for everything. It's mixes framework (HookConfig) with and forces coupling of otherwise unrelated user-facing code but anyways, it is what it is with our current config system.