This commit expands upon the previous work by creating tests around extension command execution and how various extension update scenarios are handled.
Along the way, the logic handling formatting update messaging has been switched to use `ColorScheme` in order to honor color behavior flags.
Building on logic from the `gh ext list` for retrieving and assessing extension release information, this commit enhances the logic around invoking extensions to check for new releases.
Using the same user experience from checking `gh` version, this should only output information when the extension is used and gives the user information on how to upgrade depending on the type of extension and whether it is pinned or not.
```shell
andrewfeller@Andrews-MacBook-Pro cli % gh ext install dlvhdr/gh-dash --pin v4.6.0
✓ Installed extension dlvhdr/gh-dash
✓ Pinned extension at v4.6.0
andrewfeller@Andrews-MacBook-Pro cli % ./bin/gh dash
A new release of dash is available: 4.6.0 → 4.7.0
To upgrade, run: gh extension upgrade dash --force
https://github.com/dlvhdr/gh-dash
```
This commit modifies interactive and non-interactive behaviors around `gh repo edit` as well as providing greater information about the impact.
1. `--help` usage is expanded to highlight the most significant consequences of changing visibility
1. `--help` usage and interactive experience call out GitHub Docs content that act as source of truth about full consequences of various changes
1. `gh repo edit` interactive experience will require confirmation for any visibility change
1. `gh repo edit` interactive experience will output potential stars and watchers lose regardless of visibility transition
1. `gh repo edit` will require `--visibility` flag to include new `--accept-visibility-change-consequences` flag regardless of interactivity
Based on insights gained from reviewing conventions in #9815 with @jtmcg, I'm renaming this testscript to keep consistent with `gpg-key`, `label`, `ssh-key`, etc.
As this testscript creates a Bash-based script extension, the testscript should be skipped if it isn't on the path and executable.
Ideally, we would refactor this test to isolate that portion of the tests OR switch to a Go-based extension that can be compiled and run everywhere.
Similar to `gpg-key`, `label`, `ssh-key`, this coarse grained testscript should be named after the commandset given it isn't a collection of targeted scenarios.
While swarming on this, I've encountered many merge conflicts based on
where folks have introduced new test functions. Alphabetizing them should
reduce the number of merge conflicts we encounter while introducing more
of these tests moving forward
