Redesign ExtensionService to use granular feature interfaces

Right now all editor features are exposed through a monolithic interface IEditorOperations. I think it would be better to go with a model that depends on more granular interfaces like IEditorWindowFeature which can be registered with the ExtensionService at runtime to light up that feature in the $psEditor API.

An editor integration may not want or need to expose all of the possible $psEditor features (like the $psEditor.Window section). If the editor did not register the feature interface of a particular part of the API, we would throw a NotImplementedException when the methods of that API are called. To allow callers to know whether the API is supported or not, we could provide an object on $psEditor which indicates which high-level parts of the API are supported.

This will also help with registering editor-specific feature APIs. For instance, if there are APIs which are only relevant to the VS Code editor, a feature interface could be registered for that only when the PSES language server is launched from VS Code. For any other editor, those APIs wouldn't be visible to the PowerShell session (only exposed via a "note property" added at runtime). Any developer interacting the EditorObject at runtime via C# could be able to query for the VS Code feature interface to see if those APIs are available.

Still thinking this through...

Bắt đầu bằng cách đọc ExtensionService, IEditorOperations, IEditorWindowFeature và EditorObject để hiểu API editor hiện tại và mô hình đăng ký. Issue được hoàn tất khi các tính năng có mức độ chi tiết có thể được đăng ký độc lập, các API không được hỗ trợ được xử lý như mô tả và các caller có thể truy vấn những tính năng cấp cao được hỗ trợ.