docs: add editor contributor documentation

[Kryptos-FR]

PR Details

Add in-repo technical documentation covering Stride's editor framework for engine contributors and maintainers.

Three new files and one extended file under docs/editor/:

• README.md — extended hub: ## Projects section, decision tree expanded to 7 branches (covering undo/redo, dirty tracking, Quantum feeding, selection history, custom editors, and existing editor navigation), spoke-file map updated with 3 new entries
• projects.md — complete project map for sources/presentation/ and sources/editor/: 9 assemblies with WPF coupling status, the WPF boundary rule, and where to place new ViewModel/View code
• custom-editor.md — full guide for writing a new custom asset editor: base class selection table (AssetEditorViewModel / GameEditorViewModel / AssetCompositeHierarchyEditorViewModel), generic registration attributes, 5-stage lifecycle, IEditorView template with TaskCompletionSource, services table, and MVVM patterns (MemberGraphNodeBinding<T>, manual transactions, AnonymousTaskCommand)
• editors.md — catalogue of all 8 existing editors: SpriteSheet, Scene, Prefab, UIPage, UILibrary, GraphicsCompositor, Script, VisualScript — each with a purpose paragraph, key-types table, and notable implementation details; plus a shared game-editor infrastructure section covering GameEditorViewModel, IEditorGameController, and the game-thread → UI-thread dispatch pattern

Cross-references to docs/asset-system/ (#3121) and docs/quantum/ (#3136) are included where the systems meet (e.g. MemberGraphNodeBinding<T> links to asset-graph.md; the base-class decision tree links to the asset-system editor tier guide).

Note: Anthropic's Claude contributed to writing the doc.

Motivation

The editor framework — AssetEditorViewModel, GameEditorViewModel, AssetCompositeHierarchyEditorViewModel, the registration attributes, and the lifecycle contract — is one of the harder parts of the codebase to navigate without a guide. Contributors adding a new asset type (following #3121) need to know which base class to pick, how registration works, and what the Initialize/PreviewClose/Destroy contract requires. Contributors modifying an existing editor (Scene, Prefab, UI) need to know where the code lives and how the shared infrastructure relates to the concrete subclasses.

Keeping it in-repo (following the precedent set in #3121 and #3136) means it stays versioned alongside the code, is immediately discoverable when browsing the source, and is available to AI agents without any extra context setup.

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.