Add soft-realtime priorization to velocity smoother & collision monitor

[SteveMacenski]

In the theme of #3914

@JanStaschulat quick question on rclcpp::Timers: if I use the default callback group / executor of the component given by the container, can I simply set the thread priorities in the node's constructor? The velocity smoother [1] is another area where increased priority would be helpful. I believe this is true of subscriptions, which solves the collision monitor case [2].

[1] https://github.com/ros-planning/navigation2/blob/main/nav2_velocity_smoother/src/velocity_smoother.cpp#L145-L147
[2] https://github.com/ros-planning/navigation2/blob/main/nav2_collision_monitor/src/collision_monitor_node.cpp#L66-L68

I went through the real-time workshop slides and all of the examples I found using current tooling involved creating an executor, adding nodes to it, and then spinning it in a separate thread where the priorities were set. When using Composition, which Nav2 extensively uses, we don't create our own executors to be able to control them -- the component container does. I wanted to touch base before I spent too much time on those nodes [1-2] in case there was a significant technical reason why you didn't add them in-line in the code and did so at the main.cpp level with the executor population. I suspect it was just the most general for demonstration without getting into the specifics of the nodes, but just verifying that before putting resources into it.

[SteveMacenski]

PS: Perhaps it's a good area to set soft real-time prioritization as an argument option for the component containers in rclcpp? The composition containers could have options about which node(s) or if all nodes in the container should be set with higher priority. For the single threaded and multithreaded containers; its all since they share a single executor. But the Isolated Single Threaded Container we added and use in Nav2 can have a per-node selection since each nodes gets its own isolated executor. That would be another way to generically decide at launch-time which components to make high priority without modifying the nodes themselves. That would let all of your demos then work analog to the workshop presentation slides, but now as a matter of yaml param or launch API argument instead of modifying any C++ code at all to have to manually-specify which at compile time needs what priority. That seems like an easy win!

[SteveMacenski]

#3979 Completes