Allow manual specification of parameter type

Feature request

Feature description

1. ROS Launch should allow manual type specification in a similar manner used by ROS1
2. For ambiguous value types, roslaunch should generate a warning, not silently falls back to whatever it prefers.
3. Alternatively, roslaunch should preserve both raw string value and the auto inferred value, let developer choose at runtime. i.e. get_parameter("vid").as_string() should return the raw string, including preceding spaces and zeros.

Examples:

1. xml format - with ROS1 like "type" attribute

<launch>
  <node pkg="serial" exec="serial">
    <param name="vid" type="str" value="0483"/>
    <param name="pid" type="str" value="5740"/>
    <param name="baud" type="int" value="115200"/>
  </node>
</launch>

6. python format - stick to python's type system

from launch import LaunchDescription
from launch_ros.actions import Node

def generate_launch_description():
  return LaunchDescription(
    [
      Node(
        package="serial",
        executable="serial",
        parameters=[
          {
            # Python's type system is good enough to be used like this.
            "vid": str("0483"),  # Optional str()
            "pid": "5740",       # This should also produce string, not int
            "baud": int(115200), # Should produce int, with or without int()
            "...": float(123),   # Or 123.0, should produce float
          }
        ],
      )
    ]
  )

Implementation considerations

The rationale of the requested feature is well explained in this stackexchange post. To the best of my knowledge, roslaunch for ROS2 currently does not allow any type specification. Instead it always "infers" type from the string.

For example, the current type inference will behave like this:

1. USB Pid "26ce" -> string
2. USB Pid "8087" -> int
3. USB Pid "0483" -> double (due to preceding zero)

This induces extra burdens on developer side. And more importantly, it will cause potential crash upon parameter change. A system that worked fine could be brought down just because the "smart" auto type inference. This is both dangerous and inconvenient.

Start by reviewing ROS 2 launch parameter handling and the linked Stack Exchange rationale. Compare the requested XML type attribute and Python type-preservation examples, then define which behavior is in scope and how ambiguous values should be handled. Done means the chosen behavior is implemented with coverage for the string, integer, float, and leading-zero examples.