Send device battery levels over OSC

[cubee-cb]

I've edited the osc.rs file to send HMD, controller, and tracker battery levels and charging state over OSC to VRChat.
It takes in AppState as a new parameter, but could probably pass just the raw list of devices unless we want to add more parameters like FPS or IPD, etc.

For now there is a workaround for HMD battery specifically as XSOverlay has no parameter for it, and OVR Toolkit uses an int 0-100. I implement both 0-100 as hmdBattery and 0-1 as headsetBattery.

I can only test the HMD battery on Monado at the moment (WiVRn with PICO 4), so controller batteries, tracker batteries, and SteamVR devices are untested.

Parameters are based on the XSOverlay format, excluding average battery levels but adding charging state. Charging state in my testing is delayed, I expect it only updates when the battery level is updated.

headsetBattery (float)
leftControllerBattery (float)
leftControllerCharging (bool)
tracker0Battery (float)
tracker0Charging (bool)
etc...

[galister]

there's no reason to send battery states out 10 times/second

let's add a separate timer for sending the battery states (similar to self.last_sent), once per 10s maybe?

[cubee-cb]

true.
i'm not quite understanding last_sent, i see it being set to Instant::now when the OscSender is created, but that is the only time i can see it being set. how does that know when the last message was sent?

[cubee-cb]

you know, i thought the osc debug menu was updating a little fast for 10 times per second (updated values being fully lit all the time).
i think last_sent is not being reset at all, so elapsed time is always more than 100ms, so it sends every frame instead.
i guess i'll fix that then.

i added a second Instant for the batteries that only sends after 10 seconds, and the battery parameters are constantly lit still.

[galister]

ok, mind fixing that as well?
also, we should ideally store next_send instead of last_sent so that there's less calculation involved

[cubee-cb]

next_send as in, set an instant in the future, then send once that expires?

[cubee-cb]

i've fixed the timers, i won't change them to next_send just yet because i'm not quite sure how to do that, but i might look at it tomorrow.

[galister]

that's fine, i think it's good as is. gonna run the actions and merge when i'm back