feat(robotiq_driver): expose object detection and effort as state interfaces

[ebarnett3]

Closes #26.

The hardware interface exported position and velocity only, so nothing downstream could tell a caught part from a missed one, or judge a grip. Both values already arrive in the status block the SDK exchanges every cycle.

Export effort from gCU and object_status from gOBJ. Effort is read back through the same full scale the rFR command is written against, so the effort reported and the effort requested share a scale; it stays a motor-current proxy, not a measurement of the grip. object_status carries gOBJ unchanged — 0 moving, 1 held while opening, 2 held while closing, 3 at the requested position — since a remapping would only cost consumers the manual's vocabulary.

on_init no longer demands exactly two state interfaces. A description may now declare any of the four, and is rejected only for naming a fifth the hardware cannot answer for.

Measured on a 2F-85 over a reactivation sweep: object_status ran 3 -> 0 -> 3, effort ran 0 to 92.16 N in steps of 0.9216 N, which is the 235 N full scale over the 255 counts of the register.

Verification

• 40 robotiq_driver tests pass, including three new ones: two on the register/SI round trip and one pinning the exported state-interface names.
• Fake-hardware bringup (use_fake_hardware:=true) still activates all three controllers with the two new interfaces declared.
• On a real 2F-85, ros2 control list_hardware_interfaces reports effort and object_status, and both carry live values on /dynamic_joint_states.