Allow manual specification of parameter type

[zhangyx1998]

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>

2. 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](https://robotics.stackexchange.com/questions/113001/specifying-parameter-type-in-ros2-xml-launch-file). 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`
7. 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.