Scope based editor window system

Is your feature request related to a problem? Please describe.

In the editor, editing assets have a couple of workflow and implementation issues.

• Limited customization of panel layout, meaning you can't optimize workflows or screen real-estate usage.
  • For example, you can't dock the scene hierarchy above the Property grid to give a wider viewport view.
• Inconsistent UI and UX for viewing and editing similar data, and doing similar tasks
  • For example, the entity hierarchy in the scene and the visual tree hierarchy in the UI Page both do the same thing, but are different implementations.
  • This also means repeated work for implementing improvements in to Stride.

Describe the solution you'd like

Think of each asset type as a "document scope", when a asset is opened its scope is set as the active scope. All relevant windows change to show the data of the asset when its scope is active.

Windows are designed for specific data types and tasks, instead of for specific assets. Such as Outliner, Viewport, Properties, Preview, Blackboard, and so forth.

• For example, when opening a Scene asset, if there is a Viewport window, it would show the 3D view of the scene, and if there is a Outliner window, it would show the entity hierarchy.

Windows can specify which scopes they do or don't listen to, or even specific entities (like a lock/freeze).
If a window is focused/selected that was set to a scope that is not the active scope, the active scope changes to that one. Updating all windows listening to that newly activated scope.

This allows for having multiple assets open and active at once and easily switch between editing them.

Describe alternatives you've considered

There is also the 'Unreal engine' way, where we have windows that are nested in 'main asset' windows, and opening a asset for editing opens its own window. But this duplicates a lot of windows and is not very screen real-estate friendly.

Additional context

1. Blender style Workspaces and being able to save and open groups of windows together (save a Viewport, a Bloackboard, and a Preview window set to the Material scope and save it as a "material editor" which can be opened in a new OS window). I think is a feature set that would work extremely well with this proposed window architecture, but is also something that is not core to it.
2. This proposed system only applies to windows having to do with editing assets of course, so thngs like the Output window would remain unchanged.

Closing

Beyond the obvious issues this solution addresses, it also has the benefit of overall speeding up development and providing nicer UX by default as a whole because any improvement to one window benefits all assets. Such as improving drag and drop in the Outliner would benefit the Scene, UIPage, Skeleton and any other asset that uses it, without 'any' additional work.

With the editor rewrite underway it seemed like a good time to come back and 'formally' write up this proposal. Please give any thoughts on it or ask questions.
Thanks.

The issue names no files, tests, or specific entry point; begin by reviewing the editor rewrite and existing asset-editing window architecture. Clarify the design for document scopes, window listening and focus behavior, and switching between multiple assets before implementation can be considered complete.