rqt-jtc: Make continuous sending opt-in and add Send Once button

[petertheprocess]

The rqt_joint_trajectory_controller repeatedly republishes a trajectory with a big time_from_start (~1.0 s) at 10 Hz as soon as the controller is enabled. Because the joint has already moved between successive sends, each new trajectory is re-interpolated from a slightly different current position, producing jitter in the reference and erratic joint movement on both hardware and simulation.

Changes:

• Enabling (arming) a controller no longer starts continuous sending automatically. A new "continuous send" checkbox (off by default) must be ticked to republish commands periodically, restoring the old behaviour on demand.
• Add a "Send Once" button that publishes a single trajectory on demand, independently of the continuous-send checkbox.
• Add an adjustable "start time (ms)" spin box that overrides time_from_start when > 0; 0 keeps the auto-computed duration from joint velocity limits and speed scaling.
• Add an adjustable "pub freq (Hz)" spin box for the continuous-send rate.
• Refactor trajectory building into _build_trajectory_msg() shared by both the timer callback and Send Once.
• Document the new controls in userdoc.rst and add a CHANGELOG entry.

Description

Fixes #1579

Is this user-facing behavior change?

Yes,new components are added in the GUI allowing user to set time_from_start + publish freqency mannuly.

Did you use Generative AI?

Yes, I am using GLM5.2 within opencode.

Additional Information