Various fixes for OpenXR action map meta data and editing

[BastiaanOlij]

This PR makes a number of changes around the OpenXR action map

Earlier creation of the default action map (done)

If a VR project did not yet have an action map we didn't create it until the project was first run. This causes issues in visibility and may result in a missing action map when deployed on mobile devices.

The action map is now created by the initialization of the action map editor, as this only runs if OpenXR is enabled for a project, it seemed like a good place.

Marking the resource as edited (done)

The editor has been enhanced so all actions create undo/redo entries and mark the resources as edited.

Should solve #68041

Make Action map meta data extendable (done)

The class OpenXRDefs contains meta data that details out all possible paths we can use for building our action map. OpenXR does not have a mechanism for enumerating this data.

As extensions are now being added that introduce additional paths, having this data be static is no longer enough.

To better define what this class does, I've renamed it to OpenXRInteractionProfileMetaData, turned it into a singleton and made it possible to register new paths. It is also registered with ClassDB so it can be accessed for GDExternals.

Use action map meta data for filtering (done)

Action maps need to be as complete as possible to allow games to be deployed to multiple devices, but not all devices will support the extensions required for certain entries in the action map. For this we introduced OpenXRExtensionWrapper::is_path_supported.

By completing the action map meta data and added extension information to this we can use that data to filter out unsupported entries. This will also allow us to generate warnings/errors when there are misspelled entries in the action map.

Currently OpenXR runtimes have a tendency to crash when unsupported paths are supplied.

Move registering of extension paths into extensions (future)

Note that currently extensions are only registered when OpenXRAPI is instantiated, and this class is not guaranteed to be in the editor. We need #68259 to be merged, but there is a mutual dependency here.
This PR should be merged first, then 68259, and then we can do an additional PR to clean this up.

Add ability for extensions to add entries to the default action map (future)

Again this will be dependent on the changes in 68259 to be merged so this will be in a followup PR, however currently we add default entries to our default action map including entries related to extensions.

It would be nicer if extensions can add their default entries but we need the extensions registered regardless of whether OpenXRAPI is instantiated.

This will be important for instance in our PICO extension so default PICO controllers can be setup, see #68023

[BastiaanOlij]

One question I have is whether OpenXRActionMapMetaData is the right name, it is meta data to construct our action map with, but it really is meta data describing our interaction profiles. This info says nothing about the actions a user may or may not add to their action map. I'm contemplating renaming it OpenXRIPMetaData

[BastiaanOlij]

@akien-mga @Calinou do you guys have any idea about how to solve the resource marked as edit issue? I can't find anything good about how we track this.

[BastiaanOlij]

I'm still looking for a solution to the save thing but the other bits are all done.

[BastiaanOlij]

Currently working on implementing undo/redo logic for the action map editor together with properly flagging resources are edited. After that this PR can be reviewed.

[BastiaanOlij]

Took way more time than I would have liked and I'm not 100% sure whether the approach I took was entirely right, it felt a bit round peg square hole implementing undo/redo and I might come back to this at some point as I get more experience with this system.

That said, I think this works good enough. Could defo use some feedback from the editor team.

[akien-mga]

Not sure if the emit_changed() is the right way to update things, or if it should be notify_property_list_changed() or be expected to be picked up automatically. This has always been and remains confusing to me, we really need clear documentation on what to use and when.

But this shouldn't be blocking, let's merge.

[akien-mga]

Thanks!

[KoBeWi]

Not sure if the emit_changed() is the right way to update things, or if it should be notify_property_list_changed() or be expected to be picked up automatically.

emit_changed() should be emitted whenever a Resource changes. Right now it's not done everywhere to avoid bloat, but nothing is preventing it. However, I think it should only emit when the value actually changes, not always when calling setter.

This signal is supposed to notify other resources or editors, so they can react and update. Only the inspector updates automatically.