Select Configuration using same app type for already deployed content

[sagerb]

Intent

Restrict changing a deployment's config to one with the same original content type (filtering the choices). Also, updates the select context menu to be created or selected, depending on the availability of existing filtered configs that match the current destination's content type.

Resolves #1658

Type of Change

• • [ ] Bug Fix
• • [x] New Feature
• • [ ] Breaking Change
• • [ ] Documentation
• • [ ] Refactor
• • [ ] Tooling

Approach

1. Centralized filtering logic into a single utility method (filters.ts) which is shared by both the extension and the webview.
2. New data field for content type within the deployment file was updated into the client API
3. SelectConfig multi-step input was updated to use filtering logic to configurations shown (if any) within the initial selection. If there were none available due to the filtering, then it immediately changes to a select input flow.
4. Updated package.json and commands to properly support display of contextual "create" or "select" configurations, based on availability of configs which match the selected deployment.
5. If deployment files are either pre-deployment or older versions of deployment files which do not yet have a content type entry, there is no filtering attempted. In the case of the older version, you'll get stopped with a publishing error, thanks to Mike's changes.

Automated Tests

Directions for Reviewers

You'll want to exercise the filtering and selection of configs vs. deployment files, where there are multiple content types. I'd suggest working within the multi-type content example, creating multiple destinations for the two content types and then creating additional configurations for each of them. As you are creating them within the Configurations view, there is no change of behavior from this PR. However, when you go to select them, from either the content menu or the error message (when you've gotten rid of the selected config), you'll see the filtered list. Be also aware to validate the content menu is showing correctly select vs. create, and that the multi-stepper title is changing appropriately.

Should also validate for a single project, there is no adverse impact by these changes. It all should still work as before, except for the menu option names.

Checklist

• [ ] I have updated CHANGELOG.md to cover notable changes.

[dotNomad]

Oh I misunderstood how this was working with pre-deployments. Will have another review up momentarially.