feat(hiroz): let the examples advertise their message types

[YuanYuYuan]

Slice 4 of 5, splitting #311. Sits on #319; #311 sits on this.

What this does

Makes the hiroz examples advertise their message types, and exposes the two library items an out-of-crate plugin host needs.

What fails without this

A plain hiroz node does not serve the type description service unless it asks. rclcpp and rclpy serve it by default, and hiroz's own RMW layer forces it on for every node it creates, so the examples were the only nodes on a hiroz graph that a runtime-typed consumer could not decode.

	before	after
a publishing example's node	serves no type description	serves it
hu meter echo against one	cannot obtain a schema	can
a dynamic subscriber or bridge	same	same
ZNodeBuilder::with_type_description_service	existed, undocumented as to why	documents why you want it

Two additive library items, no default changed:

item	why it is public
ZLifecycleNodeBuilder::with_type_description_service()	pass-through, so lifecycle publishers register schemas too
hiroz::dynamic::ros_type_name_from_dds	out-of-crate consumers normalise graph-reported type names the same way instead of re-deriving it

Breaking changes

What changes	Who is affected	Before to after	Action
z_pubsub node names	anyone matching on them	Sub / Pub to listener / talker	none, unless you filtered on the old names; the docs always claimed the new ones

This is a rider: it is a rename, not a type-description change. It is two lines, and separating it would make a one-line pull request.

Verification

cargo build -p hiroz --examples produces a binary for all eight edited examples. Three of them are nested files whose Cargo target names differ from their filenames — demo_nodes_talker, lifecycle_talker, z_cache_talker — so a check keyed on the filename reports a false miss.