Add R1 SDK support

[SuLvXiangXin]

This PR adds R1 support to the Python SDK.

Changes:

• Add R1 loco client APIs.
• Add R1 high-level loco example.
• Add R1 low-level ankle swing example.
• Add R1 front camera video client and examples.

Validation:

• Compared R1 high-level read-only API behavior with the C++ SDK.
• Verified low-level state parsing against the C++ SDK.
• Verified R1 camera GetImageSample returns JPEG data.

[naraka-camill]

Thank you very much. This has solved my problem. And as this interface been verified？

[JacoBezuidenhout]

Regarding the reviewer question above, "has this interface been verified?", here is a data point from real R1 EDU hardware, since the answer appears to be no for the locomotion interface.

Robot: R1 EDU, ai_sport 1.0.2.154, service sport, api version 1.0.0.0.

What works:

• 7001 GetFsmId returns 0 with correct values (0, 1, 4, 811, 816).
• 7101 SetFsmId works. Real transitions return 0, 1001 when already in that state, 1003 for an invalid id.

What does not:

• 7105 SetVelocity returns 127 unconditionally. In FSM 0, 1, 811 and 816. Hanging, on a stand, and free standing and balancing unaided. Remote powered on and off. Velocities of 0, 0.1 and 99 m/s, durations of 0, 1, -1 and 864000. It never validates its parameters, and a malformed payload returns 3202 instead, which shows the well formed one is parsed and then refused.
• 7002 GetFsmMode and 7107 SetSpeedMode return 3203, so they are not implemented on this build.

127 is not defined in r1_loco_error.hpp or internal_error.hpp, so it looks like an ai_sport application level code.

Possibly related: xr_teleoperate commit bc55c3f disables motion mode for R1_A5 and R1_A7 while leaving the implementation in place, which suggests SDK driven locomotion on R1 is currently held back.

So I would treat the R1 FSM ids and the locomotion path in this PR as unverified on 1.0.2.154. Happy to run further tests on hardware if that is useful.