Propagate launch arguments in included launch descriptions

Feature request

Feature description

There have been some previous discussion in https://github.com/ros2/launch/issues/252 https://github.com/ros2/launch/issues/249 too.
I've been discussing this a little with @hidmic, here are some of the items we discussed:

• We're currently doing a best effort checking of arguments when visiting IncludeLaunchDescription action. Launch arguments of nested launch descriptions are ignored in the process. We're also only showing those arguments when executing ros2 launch -s <PACKAGE> <LAUNCH_FILE>. But we're not checking in ros2 launch if the passed arguments were declared by the launch description or not. So currently, the launch arguments are "automatically propagated" to nested launch files, though they aren't showed to the user.
• Checking if all the launch arguments are satisfied when visiting a IncludeLaunchDescription action, including the arguments in nested launch descriptions, is hard, because some information may not be available at that moment:
  • launch file name is maybe not known.
  • name of passed launch arguments to nested IncludeLaunchDescription may not be known.
  • A SetLaunchConfiguration action may satisfy the requirement before the nested IncludeLaunchDescritpion is visited. If we do the verification anticipated, we can't be aware of that.
• If IncludeLaunchDescription actions aren't scoped (as is currently happening), we can run in the following problem:

  def get_launch_description():
    return LaunchDescription([
      IncludeLaunchDescription(
        <LAUNCH_DESCRIPTION_SOURCE_1>,
        launch_arguments={'<ARG1_NAME>': '<ARG1_VALUE>'}.items()
      ),
      IncludeLaunchDescription(
        <LAUNCH_DESCRIPTION_SOURCE_1>
      )
    ])
  

  The intention is that the first include action should use the passed arguments, and the second the defaults (the included file is the same). But the second one will use the same arguments as the first one, because of the lack of scoping.
  There are a lot of others similar issues. In general, considering that the included launch description will possible be maintained by another person, defaulting to scoped would be better (and only using non-scoped include actions when the user consciously ask for it).

I think that one possible solution to this is just showing the arguments in a different way, but keeping everything else as-is:

• List all arguments in the "first level" when doing ros2 launch -s <PACKAGE> <LAUNCH_FILE> (not showing arguments of nested launch descriptions). Add a ... at the end, or something similar, meaning that the arguments of included launch descriptions weren't showed.
• List included launch descriptions when doing ros2 launch -s <PACKAGE> <LAUNCH_FILE>. In case a path can't be resolved, show a message notifying that to the user.
• Each include launch description action is responsible of checking the satisfaction of it's arguments, but it's not responsible of checking if launch arguments of nested launch descriptions are satisfied.

The idea of this, is that all arguments that aren't re-declared, aren't directly visible to the user without digging in the documentation. But though not visible, they can still be specified by the user when running the launch file.

Start by reading launch/launch/actions/include_launch_description.py and launch/launch/launch_description.py, then compare the argument handling in ros2launch/ros2launch/api/api.py. Use the linked discussion and code locations to define the intended scoping and listing behavior; done means included launch descriptions and their argument requirements are handled consistently.