Add setting to use project from active panel

[mattlyons0]

Description of the Change

In #2308 the behavior for determining the selected project changed to use the project selected from a project management dropdown instead of using the project from the currently active pane. This behavior can be useful however I also think it can be valuable to have the old behavior, specifically when switching between several projects quickly.

In this PR I implement a setting to bring back the old behavior. The setting is disabled by default (so behavior from before this PR remains the same by default).

If enabled, the project management dropdown will become disabled (the text color changes to be more subtle in the dropdown and it is no longer selectable). It will still show the active project however it will change on its own based on the current active pane with an associated project.

This setting can be toggled and will have an impact immediately (listeners for the setting changes are all configured).

Screenshot/Gif

Disabled Project Dropdown:

New Setting:

Alternate Designs

I considered hiding the project selection UI entirely but I believe it is actually helpful to view the project name the git pane is showing for.

There are alternate designs being considered as a part of #2335 but I do not think they completely solve the issue. All of the options suggest adding at least 1 step to what the previous behavior was (at the very least, running a command to switch projects). This design does not conflict with the designs considered in that issue because they both provide different levels of autonomy to power users.

Benefits

Power users can switch project with no more effort than opening a file. I think this is a huge win for when you are working in multiple projects quickly. An example is if you say, have to update a node dependency in several projects at once and want to quickly commit the change and open a PR.

Without this setting you would need to open the package.json file, update it, find your project in the dropdown (if you have more than a few projects it can take some effort to find the correct one), then continue to do the actions with git / github.
With this setting you need to open the package.json file, updated it and then continue to do the actions with git / github.

Possible Drawbacks

It can be slightly disorienting when the selected project in git changes as you change to open files from a different project if you are not expecting it. With that said it is rare you open a file from another project unintentionally. Also if this is disabled by default you would expect this behavior since you explicitly opted in to it.

Applicable Issues

There is discussion that the previous workflow (re-added in this PR as a setting) is more useful to some: #2308 (comment)

As mentioned above there is an issue with proposed resolutions that do not fully solve the problem: #2335

Metrics

N/A

Tests

Unit tests were added to test this behavior and existing tests updated for the new pass-thru props.

Documentation

A new setting was added with a title & description. Not sure if that is what this section is referring to about documentation though.

Release Notes

• Added an option to the GitHub package to restore the previous behavior of using currently active panel for determining which project to show.

[smashwilson]

How would you feel about:

• Not putting this behind a configuration setting, just making this the context-determining behavior again; and
• Not disabling the dropdown - let the context change explicitly when users pick a project from the dropdown or implicitly when they open a new pane item.

[mattlyons0]

I'd be fine with that but I think the problem there is determining the UX for when a project is selected from the dropdown. The current behavior if I simply didn't disable the dropdown would be every time you activate a pane that has a project associated it would switch to the pane's project. Effectively if you selected from the dropdown to switch projects you would have to re-switch every time you switched files. I'm not really sure what UX would make sense for showing users they made an "override" and if it should stick for all files currently opened, all files in a project or what...

Maybe the best option is to make a dropdown item at the top of the list called Active (${activeProjectName) which will invoke the activate pane listener. If any other project is selected from the dropdown the activate listener will be ignored (and the current project will stick around until the dropdown selection is changed). This would be a bit messier technically since right now there is a bit of logic spread around the UI assuming the dropdown value is a project name, but it could be changed of course.

Let me know what you think.

[wadethestealth]

We should close this in favor of the agreed upon solution in #2335

[smashwilson]

Yah, I agree.

Thanks for taking the time to put code in place for this, @mattlyons0!