ddsi: optionally emit related_sample_identity in inline QoS

[Yu1iWoowah]

This change adds a minimal internal way to emit the existing RTPS inline QoS parameter related_sample_identity on outgoing DATA / DATA_FRAG samples.

Scope is intentionally small:

• no changes to the documented dds/dds.h API
• no generic metadata framework
• no ROS 2-specific logic
• no default behavior change

Implementation summary:

• add DDSI_PID_RELATED_SAMPLE_IDENTITY
• add a small serializer helper for the parameter
• add an optional ddsi_serdata_ops.get_related_sample_identity accessor
• emit the parameter in the transmit path only when that accessor returns true

This follows the existing get_keyhash pattern: transmit owns wire encoding, while serdata provides sample-specific data when needed.

If the accessor is absent, or returns false, behavior is unchanged.

Tests added:

• parameter absent by default
• parameter present when enabled
• serialized GUID / sequence bytes are correct
• DATA_FRAG first fragment also carries the parameter

Local verification:

• cunit_ddsi -f -s ddsi_related_sample_identity passed
• cunit_ddsi -f passed

Non-goals:

• no dds_writecdr() / dds_forwardcdr() changes
• no request/reply runtime behavior
• no broader metadata API

Main feedback requested:

1. Is this low-level capability acceptable in principle?
2. Is an optional ddsi_serdata_ops accessor the right internal hook for it?
3. If not, which internal layer would be preferred instead?

[Yu1iWoowah]

Converted to ready for review. Checks are green.