Composable package.json extension manifest contributions through the use of external files

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ --> <!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ --> <!-- Please search existing issues to avoid creating duplicates. --> <!-- Describe the feature you'd like. --> For any large extension the size of the `"contributes"` entry in `package.json` can also grow to be extremely large and difficult to maintain, especially since you cannot organize contributions by feature or add comments (since `package.json` must be pure JSON). I would propose adding something like the following to `"contributes"` to allow for composition of extension contributions from one or more external files: ```jsonc { "contributes": { "include": [ "feature1.json", "feature2.json", ... ], ... } } ``` Where `"feature1.json"` might be: ```jsonc // contributions for feature1 { "commands": [ ... ], "menus": [ ... ], // other contribution points } ``` The proposed order of composition would be: 1. Contributions provided by each file in `"include"` are applied in array order. 2. Contributions from `package.json` are applied last. In the event of a collision where two contribution sources define the same contribution (such as two commands with the same name), I see at least two options: 1. Error when activating an extension with collisions, or 2. The last in wins, but `vsce` could provide errors or warnings for collisions prior to packing/publishing. I'm generally in favor of "last in wins" so as not to hamper local development/testing while refactoring an extension, but don't have a strong preference either way. One caveat to this approach is that there would need to be some way for VS Code to know that `feature1.json` is an external contribution manifest. This could possibly be accomplished by using a well-defined filename format such as `<name>-contributions.json` (similar to `language-configuration.json`), or by using a `"$schema"` ent…