Fixes several bugs sharing the same root cause, where code/blueprints were attempting to branch on UVREditorMode::GetHMDDeviceType() or UVREditorInteractor::GetHMDDeviceType(). These calls previously returned the result of IXRTrackingSystem::GetSystemName(), and the call sites were only set up to handle "OculusHMD" or "SteamVR," and were now seeing "OpenXR". Instead, we now return one of those legacy plugin names, depending on the current OpenXR hand controller interaction profile. Longer term, we will want to revisit each of these decision points individually, and take into account support for future unknown XR devices.
An alternative subclass of UVREditorMode can now be configured in the editor settings alongside the interactor and teleporter classes, and a new UVirtualScoutingMode subclass splits the mode entry into two phases. This is necessary because OpenXR may not return the correct interaction profile for several frames after the OpenXR session / stereo rendering has started, and we need to defer creation of the interactors, etc.
#jira UE-150037
#rb jason.walter, Lauren.Barnes
#preflight 6287f49a6c7692ac8cd00f29
[CL 20302573 by zach brockway in ue5-main branch]
This migrates the mostly declarative action mappings in UVREditorInteractor::Init_Implementation into a new GetKnownActionMappings method, which we can poll in order to translate them into an OpenXR action set at the point during early initialization which OpenXR requires them to be registered. This also adds a `bIsAxis` flag to FViewportActionKeyInput, because axis mappings need to be handled differently.
The glue code leveraging this is introduced in a new VirtualScouting plugin, where we'll ultimately migrate the existing code as well (away from VirtualProductionUtilities).
#jira UE-146105
#rb Lauren.Barnes
#preflight 6261d5b00a1b9c4e192825ce
[CL 19857480 by zach brockway in ue5-main branch]
