Add support for spatial anchor storage

[maunvz]

This commit adds a way to create, persist, and load spatial anchors. An anchor represents a real world point in stage space and will remain there even if the user recenters. It is created from a Transform3D and represented as an XRPositionalTracker (with a user provided name and runtime provided uuid).

TODO: Add example to demo project

[BastiaanOlij]

Need to see how this works together with #107

Also, I really want to get rid of exposing the wrapper objects, that is a path we should never have gone down.

Godot users work with nodes and resources. We'd probably want to extend on the work in #107 where anchors that have been created previously are retrieved and added, but now you can create additional anchors or update existing anchors and their new location is communicated back to the XR runtime for storage.

One option is to introduce a new XRPersistantAnchor3D node (or subclass from XRAnchor3D) for this where any change in the transform of the node (we can detect this through notifications), we copy this transform into the associated XRPositionalTracker. We can connect to this signal from the plugin to trigger storing the new transform in the anchor storage.
Similarly creating a new anchor that needs to be stored is as simple as creating a new XRPersistantAnchor3D node and instead of setting a tracker, we tell it to create a new tracker.

The problem is that we now get bi directional communication:

• The plugin can create/update anchors when we start or when the user recenters, resulting in the XRPositionalTracker getting updated and as a result a XRPersistantAnchor3D node being created/updated,
• Or the godot side can create/reposition an XRPersistantAnchor3D node, resulting in the XRPositionalTracker getting created/updated and as a result a store anchor gets created/updated.

So we need some way to prevent this pingponging and thus have a clear way of ensuring the communication goes in the desired direction.

cc @dsnopek

[dsnopek]

I've only skimmed this so far and need to spend some more time looking at it. However, at a glance this seems to overlap and conflict a tiny bit with PR #107:

• They both add support for XR_FB_spatial_entity_storage
• This should make use of the OpenXRFbSpatialEntity class that is added in PR Add a developer-facing API for interacting with scene anchors #107 for some part of its public API

So, at the very least, this PR should probably build on top of that PR.

Also, while my (currently still private) branch isn't very far along, I had a different idea for how to expose this functionality to developers, that was similar to the OpenXRFbSceneManager node in PR #107. When I have a chance (probably not until at least next week), I'll try to finish that up and share it here.

[dsnopek]

I finally posted PR #121, which is my attempt to add a Godot-ish API for creating and persisting spatial anchors

[dsnopek]

Closing this as superseded by #121