[Launch] Allow ros launch targets to include each other idiomatically

[beekarthik]

Description

This PR introduces a custom Bazel rule (ros_launch_rule) and macro (ros_launch_macro) that automate the process of generating and executing ROS launch scripts, while handling the necessary runtime dependencies for ROS nodes, launch files, and parameter files.

Key Changes

Custom Provider

A custom provider used to propagate information about ROS nodes, launch files, and parameter files through the build graph.

• Fields:
  • nodes: A depset of node binaries or scripts to be launched.
  • launch_files: A depset of launch files defining the startup behavior of the ROS system.
  • param_files: A depset of YAML files that configure the ROS nodes.

Custom ros_launch_rule Rule

Generates a Python launch script by expanding a template.
1, Collects transitive dependencies such as node binaries, launch files, and parameter files from the current target and its dependencies.
2. Exposes these resources via the RosLaunchInfo provider, enabling downstream rules to access them.
3. Uses Bazel’s runfiles mechanism to ensure that the generated script and all required files are available at runtime.
RosLaunchInfo Provider:

Modified ros_launch Macro

• Simplifies the creation of a ROS launch target by wrapping ros_launch_rule and automatically generating a py_binary target that executes the generated script.
• Handles setting up runtime dependencies (data) and ensures all required files are included when the script is executed.

Potential Points of Contention

One potential point of contention I can already see is that the actual py_binary target is now named <target_name>_launch - happy to swap the name of the rule and py_binary if that makes for a cleaner PR (no interface breakage)

How was this Tested

Everything builds and ran examples

[mvukov]

Thanks for the contribution. What's the use-case here? Can you add an example or even better a test for this new feature?