Cross-vendor TypeConsistency: consume standard PID_TYPE_INFORMATION for assignability at match time

[SandraK82]

Summary

Cross-vendor type matching falls back to the topic type name because ZeroDDS does not yet consume a peer's standard PID_TYPE_INFORMATION. As a result the XTypes assignability / TypeConsistencyEnforcement path is never exercised against other vendors (CycloneDDS, Fast DDS, RTI), so an extensibility mismatch (e.g. @final vs @appendable) produces a match followed by a decode failure rather than a match-time rejection.

This surfaced while investigating #27 and is not fixed by that PR (#27 fixes the codegen default via --cyclone; this is the deeper matching-path limitation).

Current behaviour

• ZeroDDS derives a matching TypeIdentifier only from its own vendor PID (ZERODDS_TYPE_ID), which other vendors don't send. A peer's standard PID_TYPE_INFORMATION blob is stored on discovery but never converted into a comparable TypeIdentifier.
• With pubd.type_identifier == None, the assignability guard is skipped and matching falls to exact type name.
• DataReaderQos does not expose TypeConsistencyEnforcement, so force_type_validation is not user-reachable.

Proposed

• Parse the standard PID_TYPE_INFORMATION into a TypeIdentifier / TypeObject so cross-vendor endpoints can be checked for assignability.
• Wire the standard TypeConsistency path so incompatible extensibility is rejected at match time (OfferedIncompatibleQos / no match), instead of matching + failing to decode.
• Expose TypeConsistencyEnforcementQosPolicy on DataReaderQos.

Scope

Enhancement / spec-completeness. Separate from #27. Would also feed the dds-xtypes conformance track (TypeInformation / TypeConsistency / TypeObjects).