turtlebot4_navigation/localization.launch.py does not accept command line params_file argument

[slowrunner]

Describe the the feature you would like

turtlebot4_navigation.launch.py should accept a command line params_file argument:

ros2 launch turtlebot4_navigation localization.launch.py \
  map:=/home/ubuntu/TB5-WaLI/wali_ws/maps/tb4_nav_async_w_chrony.map.yaml \
  params_file:=/home/ubuntu/TB5-WaLI/wali_ws/params/test.localization.yaml

User could copy turtlebot4_navigation/config/localization.yaml to their ROS workspace/params/ folder,
and test with less beams, or reduced min/max particles - e.g.

ubuntu@TB5WaLI:~/TB5-WaLI/wali_ws/params$ diff wali.localization.yaml.gemini localization.yaml.orig_tb4_nav_config 
1c1
< amcl:   # was values from released tb4_nav/config/localization.yaml
---
> amcl:
19,21c19,21
<     max_beams: 30  # was 60
<     max_particles: 800  # was 2000
<     min_particles: 200 # was 500
---
>     max_beams: 60
>     max_particles: 2000
>     min_particles: 500
29c29
<     save_pose_rate: -1.0  # was 0.5
---
>     save_pose_rate: 0.5

Note: the released nav2.launch.py does accept params_file command line parameter already.

Motivation and impact

Since the current Jazzy release turtlebot4_navigation.launch.py does not accept command line params_file argument, TurtleBot4 users cannot (easily) investigate localization parameter changes.

The need to test with custom localization parameters came up in Google Gemini directed debugging sessions. The issue trying to be solved was "Issuing ros2 topic echo --once /battery_status while TurtleBot4 is navigating a path will cause goal failure", and Gemini suggested parameter changes to both localization and navigation to reduce CPU load.

(A total waste of time - None of the suggestions actually decreased CPU load, and the issue turned out to be unrelated to CPU load - result of ros2/rmw_fastrtps#741 )

Other notes

No response