Add Velocity calculation logic and GUI toggle (end-to-end MVP).

[M1DNYT3]

This PR completes velocity transmission end-to-end, adding RPC settings and a GUI toggle on top of the foundation from #1754.

What's added:

• Protobuf velocity transmission via ProtobufBridge, per-tracker
• RPC settings support - toggle persists across restarts
• GUI toggle in General Settings with i18n

Toggle's GUI Path:
Settings > General > Tracker Settings > Toggle is at the very bottom of the section.

Technicalities:
Most of the line count (~400) comes from regenerated ProtobufMessages.java. The handwritten change itself is small.

Depends on SlimeVR/SolarXR-Protocol#202, should be merged only after the submodule is updated to the tracked HEAD.

Addresses the issue: #25

[M1DNYT3]

Force pushes in history are changes made by spotless.
For some reason, one application wasn't enough for it to fix all the issues in Tracker.kt, so I had to push it twice, and I didn't want to make 2 separate commits for spotless alone.

[M1DNYT3]

At some point, I had a conversation with @ButterscotchV in DMs, and there was a recommendation expressed to ship the whole feature (Implying a toggle, nothing overkill) in one PR.

The description is edited accordingly to reflect each affected part of the code.
The handwritten part (meaning not regenerated flatbuf, and not regenerated ProtobufMessages) follows the existing code architecture 1:1 and reuses the methods, styles, and classes, where necessary.

[M1DNYT3]

I had some additional feedback from @ButterscotchV in DMs, addressed it all + rebased to the latest main + also did some changes of my own.

Feedback changes:

• drop applyVelocityPolicyTo() in VRServer.kt; initially made for expandability, but turned out to be redundant because VRConfig.applyVelocityPolicy() already covers expandability.
• replace System.nanoTime() with Kotlin's TimeSource; self-explaining, did precisely that.

My own improvement:
Noticed that I forgot to wire hasVelocity instead of allowVelocity in the ProtobufBridge.kt; the former was created for a safeguard to not send anything if we don't have any velocity in the tracker. Technically, both calls would result in the same behavior, but hasVelocity follows architecture better and explicitly states that there has to be something for it to be sent, whereas allowVelocity simply states whether the toggle is on or off.

[M1DNYT3]

Review changes were shipped and tested E2E with SteamVR.

One thing to note. Jitter is still noticeable. I may think of a one-euro filter or some velocity smoothing added, but I suggest that to be a separate PR once this one is shipped.

[ButterscotchV]

Looks fine, SolarXR needs to be merged/fixed before this PR.

[ImSapphire]

"policy" is a wording not used in the rest of the codebase and was confusing for me on the first read. This should probably be named updateTrackersVelocitySettings, like in ResetsConfig.

[ImSapphire]

Could be shortened

Suggested change

	/**
	* Updates the derived velocity of the tracker by differentiating position over time.
	*
	* This method enforces the [allowVelocity] policy and checks for valid position data before
	* proceeding. If conditions are met, it calculates velocity based on the displacement since the
	* last update, applying a sanity check on the time delta to filter out noise and ensure data stability.
	*
	*/
	/**
	* If derived velocity is enabled, updates the derived velocity of the tracker, calculating it based on the position displacement
	* since the last update, applying a sanity check on the time delta to filter out noise and ensure data stability.
	*
	*/