POC: Change Experience Plugins

[elliot-nelson]

Summary

A work in progress draft of the change experience provider plugin. Implements features described in #3725.

Details

There's three main areas of interest in this PR:

1. Creation of a new plugin provider, IChangeExperienceProvider, and the associated interfaces and types.
2. Modifications to ChangeAction to load up change experience factories and interact with providers from plugins.
3. An example plugin, ExampleChangePlugin, to try and dogfood the interface above. The code here is sloppy and intended only for prototyping; in real life, the intent would be that companies could create their own private plugins to customize the rush change experience for developers.

This is just a prototype; the inquirer types appear to be a hot mess, so I had to turn off type checking on libs in all downstream projects to get it building.

Example plugin in action:

Example plugin features

Although the example plugin is just a demo and would not be checked into Rushstack, it's probably useful to understand what it is trying to do (because this ends up shaping the interface of IChangeExperienceProvider).

Here's a list of the features currently implemented:

• The plugin adds a new custom prompt, asking for a JIRA Ticket -- this is stored as customFields.jiraTicket in the change file.
• If developer types rush change --commit-message "feat: ABC-123 add a button", the plugin deconstructs the message as if it was a conventional commit, and provides defaults for any prompts in that round. (so, bump type would default to "minor", message would default to "adds a button", and jira ticket would default to "ABC-123"). This is a "conventional to change file" default.
• If the developer types rush change --commit, and they've made a normal commit to the current branch in the last hour, we'll grab the most recent commit and perform the same deconstruction on it, defaulting message and bump type / jira ticket if we can extract them. (Example: git commit -m "ABC-123 add a button" ; rush change --commit).
• If the developer types rush change --commit, when we go to commit created change files, we take the bump type, jira ticket, and message of the first change prompt and format it as a commit (this might or might not make it identical to the last commit they performed, it depends on whether they updated the default).