Add a developer-facing API for interacting with scene anchors

[dsnopek]

This builds on the work from PR #66 which added extension wrappers for XR_FB_scene and all the related extensions, but didn't expose a nice developer-facing API.

This PR adds that API!

It's centered around a new OpenXRFbSceneManager node, where you configure scenes to be instantiated for each scene anchor depending on it's semantic labels:

For each scene anchor that it discovers, it creates an XRAnchor3D node (which gets its position from an XRPositionTracker) <-- this is the generic support for anchors already built into Godot, which is also used by the ARKit plugin

And then depending on the semantic labels of the scene anchor, it instantiates the given scene and makes it a child of the XRAnchor3D, and calls a method on it with an OpenXRFbSpatialEntity object, which the developer can use to query any information they want about the anchor, for example, including easily creating a MeshInstance3D or CollisionShape3D.

The demo project uses this to place some boxes and labels in the room based on the captured scene data:

Press the Y button to toggle on/off passthrough (the scene anchors will only be shown when in passthrough) and the Menu button to do scene capture.

I also took the opportunity to make a friendlier way to access the scene capture API. Rather than calling OpenXRFbSceneCaptureExtensionWrapper.request_scene_capture(), this PR adds a similar method on the OpenXRFbSceneManager node, so developers should be able to do everything related to scene anchors via that node (never having to interact with the singletons).

This PR was already getting huge, so there's a couple things I've left out for now, which I plan to add in follow-ups:

• Getting the triangle mesh for an anchor - this requires integrating with the XR_FB_triangle_mesh extension
• Developer-created spatial anchors (this PR only covers scene anchors)

[m4gr3d]

Out of curiosity, wouldn't a quad mesh be more appropriate here?

[dsnopek]

No, I don't think so. My understanding is that a QuadMesh is just like a PlaneMesh, except it's oriented towards Z+. The anchors are oriented towards Z-, which we get by rotating the mesh instance 90 degrees around the X-axis. I guess we could use a QuadMesh and then rotate it 180 degrees around the Y-axis, but I don't think we really gain anything by doing it that way? And the the way it is currently in the PR makes it consistent with how we handle the collision shape, which I think is a good thing.

[BastiaanOlij]

Yeah Quadmesh is a subclass of PlaneMesh with just some different default settings, it's mostly a convenience as this is often used for billboarding. So I would use PlaneMesh in most scenarios.

[BastiaanOlij]

Sorry, didn't see the PR till now. I need to play around with this some day but purely looking at this from a code perspective, this looks really nice!

It needs documentation, both from a user POV and from someone who wants to understand the underlying approach, but we need to decide on a place to add this. Maybe we should add a help system similar to what we did with XR tools?