feat(equivalences): support per-field ROS type overrides

[MerinoSheep]

Proposed changes

Adds field_type_overrides: a map from fully qualified Protobuf field name to ROS type, overriding one field's ROS type without touching the .proto.

Protobuf has no fixed-size arrays, so a covariance matrix must be repeated double. ROS has float64[36]. Existing message_mapping and package_mapping only remap whole message types.

field_type_overrides:
  proto2ros_tests.FixedSizeVector.values: float64[3]

Changes:

• Configuration.field_type_overrides + README row.
• translate_field resolves the override by field FQN, in place of translate_type.
• New fixed-size array branch in both conversion templates — std::array has no clear()/reserve()/assign().

Protobuf -> ROS, by source length:

Length	Behavior
0	zero-fill (field left unset)
N	copy
other	throw / raise

Partial copies are never produced. ROS -> Protobuf needs no special handling.

Rejected at generation time:

• repeated field, override not a fixed-size array
• repeated field, composite element type (no conversion code generated for these)
• singular field, array override
• override combined with an any expansion

Checklist

• Lint and unit tests pass locally
• I have added tests that prove my changes are effective
• I have added necessary documentation to communicate the changes

Additional comments

Run in containers from .devcontainer/Dockerfile via the CI chain (colcon build && colcon test && colcon test-result --all --verbose):

Distro	Result
humble	45 tests, 0 errors, 0 failures
jazzy	45 tests, 0 errors, 0 failures

Lint clean at pinned .pre-commit-config.yaml versions (ruff 0.14.4, black 25.11.0, mypy 1.18.2, cpplint 1.6.1, clang-format 16.0.2).

The zero-fill literal is type-derived (0.0, False, "", 0) — generated Python type checks each array item, so a bare 0 is rejected for float64[N]. C++ uses .fill({}).

Repeated composite overrides are a possible follow-up: the composite branch of both templates would need the same three cases, using indexed assignment instead of emplace_back.

[mhidalgo-rai]

@MerinoSheep thanks for the contribution, and sorry for delay. This one fell off my radar.

Code itself looks correct, but the functionality does make me wonder. Is it more general than it can be? The set of field type override tuples we can automatically handle is quite narrow when accounting for conversion code. That's why message re-mapping are whole.

So should this be a field_bounds setting instead?