Expose the full gripper command and status blocks to ROS

[ebarnett3]

The SDK exposes the full gripper command and status blocks, but the ROS layer does not pass most of it through. A ROS consumer today sees position (state + command), a derived velocity, and the two activation command interfaces — everything else the gripper reports on every cycle stops at the hardware interface.

What should be reachable from ROS:

• Status: the complete status block — gACT, gGTO, gSTA, gOBJ, gFLT, gPR, gPO, gCU. Object detection and current are tracked separately in robotiq_driver: expose effort (gCU) and object-detection (gOBJ) state interfaces #26 as ros2_control state interfaces; this issue is the broader question of publishing the whole block.
• Command: the values actually being written each cycle (rACT, rGTO, rATR, rPR, rSP, rFR), so a consumer can see what the driver is sending rather than inferring it.

Open questions

• Interface choice. ros2_control state/command interfaces cover what a controller needs, but they are a poor fit for diagnostics — nothing outside the controller manager can read them. A latched topic (or a diagnostics topic) publishing the decoded blocks is the natural complement. Deciding which values go where is the substance of this issue.
• Rate. The exchange cycle runs far faster than anything needs to consume the status for display. A publisher needs its own rate, decoupled from the control loop.
• Naming. Whether topics expose raw register names (gPR, gOBJ) or decoded semantics. Raw names match the manual and are unambiguous; decoded names are friendlier to someone who has never read it.

An inspection/control surface for basic commands (rviz panel or a small web viewer) is the eventual goal, but it depends on this being published first.