Add Input Interaction System to supersede mouse capture system and register custom editor services

[Basewq]

PR Details

A simpler take for the ability to extend to the scene editor #3183 (or at least the initial ground work for plugin support).

Change 1:
This is similar to 'mouse capture', but instead of checking IsMouseAvailable & setting IsControllingMouse to take immediate control, the services submit a request to InputInteractionRequest to IInputInteractionService which then resolves the winner by InputInteractionType priority (and sub-priority InputInteractionRequest.Order) on its own update.

This solves 2 issues:

1. Editor Services can execute in any order (and with async script code if wanted), and assuming they participate properly with the interaction system, mutating asset code is just done within the IInputInteraction object if it wins the request.
2. This resolves the multiple systems fighting for control, since Camera/SceneSelection/Tools/Gizmo have different priorities (see InputInteractionType enum).

Most *Service classes have minimal changes, ie. TransformationGizmo inherits IInputInteraction directly to keep the code same-ish, whereas EditorGameMaterialHighlightService/EditorGameEntitySelectionService show the usual way to do it. (see Change 3 for details on EditorGameEntityCameraService changes).

Change 2:
New StrideAssetsPlugin.RegisterGameServices method. This is more of a dirty hack to just allow developers (ie. me) to register my editor service while we still wait for the formal design of the plugin system.
My guess is that the proper solution would be registering tool classes via inheritance/attribute.
Not sure if there's a way to mark this as experimental/use at your own risk? Though there's no real documentation on the current plugin system (which already isn't usable without reflection) so it shouldn't matter?

Change 3:
The original camera code is a bit quirky, so I've keep most of the existing code/behavior in place then worked my 'fixes' around it, but there are some subtle new changes to it.
There are now three 'hard' modes to the camera: FreeLook, Pan, Orbit. When you enter one of the modes, the only way to exit it is by releasing the main button you originally used.
eg. RMB -> FreeLook -> release RMB, MMB -> Pan -> release MMB, Alt + LMB -> Orbit -> release LMB (note that releasing Alt key still keeps you in orbit mode, unlike the original code).
The original code lets you go in and out of any of the modes if you had enough hand dexterity. (Technically there's a 4th "mode", which is just mouse wheel when not in a mode, which I've also kept in).
A nicer cleanup would be to have 3 separate Interactions for each mode but there might be some code duplication.
Also orbit doesn't always seem to work (ie. the pivot position feels wrong), but this is just retained behavior from the original code,

Why this is still in draft mode

Probably need feedback on the proposal.

1. Is this 'capture' design appropriate? The alternative is doing what other editors do, which is InputEvent consumption (e.Handled()).
2. Are InputInteractionSystem & IInputInteractionService good enough names?
3. Are the files in the right place? (I randomly dumped 'interactions' in Stride.Engine) There is also the question whether this could be used by non-editor code (unlikely due to how basic and targeted it is for the editor).
4. Is this 'capture' too general? This enforces only one interaction (assuming they participate), though we probably could introduce new fields in the future if you want something like device only capture to allow for weird setup like multi users?

Possible future extensions (not for this PR)

1. IInputInteractionService.ForceTerminateActiveInteraction & IInputInteraction.Cancel aren't used in the code.
   IInputInteractionService.ForceTerminateActiveInteraction might be usable if we wanted a semi-global Esc key to cancel in-progress interactions.
2. Instead of polling on input IsPressed, poll or subscribe against gestures, eg. life cycle of the IInputInteraction could be driven by a drag gesture.

Related Issue

Original issue submission: #3183 (Need ability to extend to the scene editor)

My sync TransformationGizmo update #3186 will be dropped in favor for this, however this does mean the existing entity duplication quirk will persist (ie. Ctrl+drag -> entities generated upfront in one transaction and may freeze if too many entities selected, then a 2nd transaction for the transform update).

This PR obviously doesn't solve the whole plugin system issue, eg.

1. No formalized direction on plugin registration.
2. Proper hotkey system (especially around blocking/overriding certain keys like Del)
3. EditorGameEntitySelectionService is targeted for entity selection instead of generalizing it to allowing for things like spline/vertex/etc selection (though this can easily be worked around).

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My change requires a change to the documentation.
• I have added tests to cover my changes.
• All new and existing tests passed.
• I have built and run the editor to try this change out.

[github-actions]

🤖 Draft PR — automatic CI is skipped to save runner minutes.

• Mark the PR ready for review to run the full automatic CI — or add a ci-run-on-draft label to run it now without leaving draft.
• Or arm a specific opt-in suite: ci-enduser, ci-editor, ci-ios, ci-android.