feat: Normalize IMU data and use buffers for IMU's

[pastaq]

This PR does a major overhaul of how IMU data is managed across every aspect of InputPlumber.

• All source device drivers now normalize IMU data into radians per second for gyroscope data and meters per second squared for accelerometer data.
• All target devices now denormalize Accelerometer and Gyroscope events into their native format (typically LSB).
• The iio_imu source device driver now configures a buffer and follows an asynchronous drain/refill pattern to create events. This reduces CPU and RAM overhead by reducing the number of reads per event from 3-6 to 1. This also has the benefit of reducing jitter when using iio_imu based devices as the entire event is now based on a single timestamp, when the old method had significant drift during each poll.

[ilyasturki]

I hit the DS5 accelerometer saturation this PR fixes: the hidraw source forwards raw counts, denormalize_accel_value scales them a second time, the i16 saturates, and the emulated pad has no usable gravity vector left.

Reading the new constants, the forward direction looks right but the inverses look wrong. Each pair should round-trip to 1 and neither does:

DS5_ACCEL_TO_SI  × DS5_SI_TO_ACCEL  = 0.00119710083 × 0.101971621 = 1/8192
DS5_GYRO_TO_RADS × DS5_RADS_TO_GYRO = 0.00001706026 × 57.29577951 ≈ 1/1024

Raw to SI to raw loses the resolution factor each time.

constant	value	equals	verdict
DS5_ACCEL_TO_SI	0.00119710083	9.80665 / 8192, raw to m/s²	correct
DS5_SI_TO_ACCEL	0.101971621	1 / 9.80665, m/s² to G	should be 835.352 = 8192 / 9.80665
DS5_GYRO_TO_RADS	0.00001706026	(π/180) / 1024, raw to rad/s	correct
DS5_RADS_TO_GYRO	57.29577951	180 / π, rad/s to deg/s	should be 58670.9 = 1024 · 180/π

The driver applies the forward constants as raw to SI (state.accel_x.to_primitive() as f64 * DS5_ACCEL_TO_SI), so nothing compensates further down. As written denormalize_accel_value(9.80665) returns 1 where the target's own calibration report advertises 8192, and the gyro path is off by the same 1024.

denormalize_gyro_value also still takes value_degrees_sec while its doc comment now says radians per second.

I have DualSense Edge hardware on Bluetooth and USB. I can test the branch and send the constant fix as a PR against it.

[pastaq]

Awesome, thanks. This PR is kinda stuck at the moment but I plan to break it up into a few separate PR's. I haven't gone through to validate all the value changes, I think I made quite a few mistakes. I'll be sure to review your input here when I'm working on the SI standardization piece.

[SimpleMatt7]

Tested motion through SDL on a ROG Ally X (BMI323) and wrote up the details in #715. Some notes that may help
when this gets split up:

• DECK_SI_TO_ACCEL = 1632.65 gives 16011 LSB/g; SDL's Deck driver uses 16384 LSB/g (1670.7 per m/s²).
  DECK_RADS_TO_GYRO = 916.73 gives 16.0 LSB per °/s; SDL uses 32768/2000 = 16.384 (938.7 per rad/s).

• The Deck targets also need an axis remap: SDL reads the Deck report as (X, Z, -Y), so the target should
  write (X, -Z, Y). I verified this with static poses on a patched v0.79.0 build (flat: acc Y = −16545,
  upright: acc Z = +16350, right edge up: acc X = +16230).

• On the DualSense target, sensor_timestamp advances by 3 per write_event instead of real time, and the
  calibration feature report (0x05) has a 5-byte bias block, so SDL reads roll bias = −31745 and discards the
  calibration. Neither is touched by this PR.

  Disclosure: written with the help of Claude (Anthropic); measurements and tests done on my device