Event based infrastructure state update

[luca-della-vedova]

New feature implementation

Implemented feature

Part of open-rmf/rmf_simulation#114, to make the visualization more scalable for larger facilities.

Implementation description

This PR changes the rmf_visualization_building_systems to work with doors and lifts only publish an update when a new subscriber is detected or a state change takes place.
This required a few changes:

• Increase the depth size of the door / lift subscriptions.
• Always publish all the markers whenever a new state is received. This makes sure late publishers always receive the state of all infrastructure.
• Always store the state of all doors. This has the benefit that now the plugin is slightly more "responsive" to map changes since the markers can be switched immediately when the map is changed, compared to previously that they would only be displayed when the next state update comes in.

Marked as a draft as I work on the PRs across the other repositories and make sure they all work well together.

[luca-della-vedova]

This PR is now ready for review.
Similar to its counterpart in rmf_ros2, it should be a UX improvement independent of the event based logic. Specifically it will have:

• Lower latency with door display when switching floors, since door data is now cached and we don't need to wait for the next state update to come before displaying a door.
• Fixed a long standing issue where if the name of the floor is non existing we still display doors and lifts.

The main cost will be a larger payload on the rviz marker topic since we publish the whole state.

The CI failure seems due to vision_msgs not being in rolling and it seems to have been introduced around the time the 24.04 transition took place. I think it can be ignored for now and we can troubleshoot it if it sticks until the next rolling sync.

[luca-della-vedova]

I'll temporarily mark this as draft while I figure out what to do with it. The changes are not necessary anymore now that the event based logic was reverted in rmf_simulation, so we can either leave rmf_visualization unchanged or just select the fixes and leave out the performance cost (serializing and sending the whole state in rviz)