Many API Additions

[hammy275]

This PR adds a lot of additions to Vivecraft's API, making it about on-par with MC VR API. This PR is intended to replace MC VR API, though I plan to maintain MC VR API for the rest of the major Minecraft version this PR is merged into (as of writing, for the rest of Minecraft 1.20.x).

This PR also rewrites the Tracker system. Tracker is now an interface instead of an abstract class, and EntryPoint was replaced with TrackerTickType.

Lastly, this PR removes all beta markers from the API, with the exception of isVanillaRenderPass(). This can be reverted if wanted.

I'm very much looking for feedback. Anything from method names, to organization, to behavior, I'm greatly interested in hearing it. Especially considering that the API should be prepared for Vivecraft to grow.

Some notable differences between this PR and MC VR API:

• This PR adds support for client-side history of position and rotation data going back up to 20 ticks.
• This PR adds support for opening/closing Vivecraft's keyboard.
• Add support for mods to supply their own Trackers to run alongside Vivecraft's.
• Server-side haptic pulses are not available. This was intentional, and was done mainly to force developers to trigger haptic pulses on the client-side at the same time as whatever event they're performing. If there's demand for server-side haptic pulse triggering, I can add that as a packet.
• Nearly all interface names are different between this PR and MC VR API.

EDIT: I'm currently developing an example mod that uses parts of the PR. It's pretty heavily commented, as it would hopefully make a good example if this PR is merged. Note that you should not look at any releases before version 2.0.0, as those were a showcase of MC VR API, rather than this PR.

[hammy275]

Force pushed a rebase to fix merge conflicts

[ferriarnus]

A quick review, most seems good!

[hammy275]

Just as an update on this PR so it's in writing on the tracker, this PR is still alive, just that I'm low on time to work on it right now. I consider the PR itself practically done, just that I want to finish the example mod mentioned above so it can be used to fully bug-test the API in some way. This is how I caught the issue with world scale that was fixed in ca0aa50 and 4ef41f4. Once that's done and the merge conflicts are fixed, I'll ask for another round of reviews, though if people want to provide them sooner, feel free to.

[hammy275]

Finally finished the example mod. It should test to some degree every feature of the API by adding a few custom items that use API features. Note that I haven't tested the mod under Forge, but all is tested and working under Fabric, and I don't see why this API wouldn't work under Forge.

That said, this is ready for review, testing, and any feedback (bugs, API changes big or small, or any other feedback).

[fayer3]

should maybe add a method to get the current renderpass, and one to check if it's the first one

[hammy275]

Both sound good to me! I'll mark them as @Beta, similar to the isVanillaRenderPass() that exists right now.

From what I remember of Vivecraft rendering, is the first render pass always RenderPass.LEFT, or is it more dynamic than that?

[fayer3]

it should be left, but we have a separate flag, that you should use
https://github.com/Vivecraft/VivecraftMod/blob/Multiloader-1.20/common/src/main/java/org/vivecraft/client_vr/ClientDataHolderVR.java#L54

[hammy275]

Closing this PR, with #255 to take its place, which includes the requested ability to get the current render pass and if it's the first render pass.