Issue 96/use gripper's object status to determine the ROS stalled and reached_goal states

[ebarnett3]

Closes #96.

The ROS parallel_gripper_action_controller class decides stalled and reached_goal states from the joint velocity alone. The Robotiq adaptive grippers report these states directly as the object_detection, state so there is no need to use the velocity. In fact, the velocity would provide a significantly worse measure, since it would need to be computed based on a finite difference of the actual position.

Therefore, the purpose of the changes here are create a gripper action controller that uses the object_detection reported by the gripper by default for determining the stalled and reached_goal states: robotiq_controllers/GripperActionController derives from the parallel_gripper_action_controller and adds one parameter, use_object_status. With it on, a goal is stalled when the gripper reports an object while opening or closing and reached_goal when it reports the requested position or meets goal_tolerance; the stock stall timeout is disabled, so only the gripper can call a stall. The joint must export object_status; the controller refuses to activate otherwise, rather than claiming every state interface in the controller manager to look for it. Because the gripper keeps reporting the previous goal's outcome until it acts on the new target, a settled state counts only once it differs from the value read at goal acceptance or once motion was seen; a goal that never shows either is decided by goal_tolerance alone.

The flag ships on in the driver config: there is no stock behaviour to preserve, since the driver's velocity is always zero and every goal came back stalled (#29). The ros2_control mock exports no object_status, so it gets a config of its own with the flag off, selected by the launch like the topic-based one; the SDK's simulated gripper (robotiq/grippers#37) will run behind the driver and need none. Controller name, action, result fields and parameters are unchanged. Bench on a 2F-85 with #92 merged locally: 40 free cycles with no false stall in either mode; closing on a 35 mm block, the stall verdict came 10 ms after the fingers stopped with the flag on, 1.8 s with it off, when using velocity estimation. Humble, whose stock GripperCommand controller has the same velocity stall, gets the same parameter in a follow-up PR stacked on this one.

Verified on Jazzy (new gtest through an action client; mock and SDK fake bringups, each activating all four controllers and reaching a goal), and built with tests in ros:lyrical and ros:humble containers.

[l-tschreiber-a11y]

Automated review pass (Claude Code). No blocking bugs — the object-status verdict logic is sound and well covered by the new gtest suite. A few behavioral notes and nits posted inline; the two I'd weigh before merge are the decode() message-suppression change and the coupling of the disabled stock stall to base internals.