Add zone messages for GoToZone feature

[chart-singapore]

New feature implementation

Implemented feature

This is part of an 8-repo Simple GoToZone feature. Tracked in Stage A of open-rmf/rmf#726.

Adds a new rmf_zone_msgs package containing seven message types that form the zone-booking protocol between fleet adapters and a new Zone Supervisor node.

Implementation description

Messages

Message	Direction	Role
ZoneRequest	Fleet Adapter --> Zone Supervisor	ENTRY / EXIT request with modifiers
ZoneState	Zone Supervisor --> Fleet Adapter	Event-driven snapshot of all bookings + rejections
ZoneBooking	Inside ZoneState	Confirmed booking (waypoint, orientation, identity)
ZoneRejection	Inside ZoneState	Rejection with reason + request_id correlation
ZoneModifiers	Inside ZoneRequest	group_hint, orientation_hint, preferred_waypoints
ZoneBookingRevoked	Zone Supervisor --> Fleet Adapter	Forced revocation (stale booking, manual release)
ZoneManualRelease	External tool --> Zone Supervisor	Operator override

GenAI Use

We follow OSRA's policy on GenAI tools

• I used a GenAI tool in this PR.
• I did not use GenAI

[mxgrey]

Before I give feedback on the message definitions I'd like to know which criteria you would rather I review this with:

1. How well it conforms to the practices of the "current generation" (i.e. what is currently in rmf_internal_msgs)
2. How well it aligns with the design patterns that we're planning for the next generation (i.e. what's being proposed in next_gen_prototype)

Going with criteria (1) will probably mean that requested changes for this PR will be minimal, but we may need to substantially revise the ROS interfaces for zones when we migrate them to the next generation.

Going with criteria (2) will probably result in substantial change requests for this PR, which would likely cascade into changes needed in your PRs for rmf_ros2 and any thirdparty code that you currently have which uses these messages. However the eventual transition to the next generation will require little or no changes.

I think either approach has advantages and disadvantages, and I would be happy to accommodate whichever you would prefer.

[kjchee]

Before I give feedback on the message definitions I'd like to know which criteria you would rather I review this with:

1. How well it conforms to the practices of the "current generation" (i.e. what is currently in rmf_internal_msgs)
2. How well it aligns with the design patterns that we're planning for the next generation (i.e. what's being proposed in next_gen_prototype)

Hi @mxgrey , let's go with criteria 2 (align with design pattern of next-gen).
We're happy to make the changes now, and to cascade the resulting updates into rmf_ros2.