WebXR Anchor system should provide full abstraction on top of XRAnchor

[Alex-MSFT]

Currently in the WebXRAnchorSystem the underlying XRAnchor is exposed directly to the user, and the only way to delete an anchor is by calling anchor.xrAnchor.delete(). This goes against the typical design of WebXR features in Babylon where we create a full abstraction on the object to make it resistant to API surface area changes.

I would propose removing access to the XRAnchor object, and adding in a remove method to the WebXRAnchorSystem that allows users to explicitly remove the object. '
eg:
IWebXRAnchorSystem.remove(anchor: IWebXRAnchor)

Additionally the promise returned by the creation functions is to the underlying XRAnchor object, which means that it is not actually yet available to be used by the consuming application as we cannot attach BabylonNodes to it or work against the anchor.

Since this API is already asynchronous I think it would make sense to have it not resolve the promise until we have a valid IWebXRAnchor. This would allow us to more cleanly create and attach to anchors without having to track across callbacks.

eg.
const transform = new TransformNode();
const webXRAnchor = await addAnchorAtPositionAndRotationAsync(Vector3.Zero(), Quaternion.Identity());
webXRAnchor.attachedNode = transform;

[RaananW]

@Alex-MSFT - promises will now resolved only when the anchor is tracked (great suggestion!) and are resolved with the IWebXRAnchor object, which now also has a remove() function. I preferred to keep it at the Anchor level, as I want to avoid a filter/find call every time we search by ID.

I made a few more changes here - #9282.

Closing this, please reopen if there is anything I didn't address.

[carstenschwede]

I'd like to test this out. Which currently available device/browser combination allows testing for anchors?