Provide a user-accessible way to revert to older MM version

**Describe the bug**
Especially lately, Metamask has been forcing updates that break dApps without notice. For examples:
- An update which [caused chainChanged to be emitted on every page load](https://github.com/MetaMask/inpage-provider/issues/110), producing some infinite reload loops and making dApps unusable, especially where programmed to refresh onChainChanged.
- Adding the chainId validation as a strict requirement for connection even on private networks [broke](https://github.com/MetaMask/metamask-extension/issues/9683) dapps running on chains/nodes that do not implement the chain_id method, including those connecting to older versions of geth.
- [Performance issues in one of the most recent updates](https://github.com/MetaMask/metamask-extension/issues/10097) cause Metamask to freeze and/or crash out completely on certain common actions, making some dApps unusable.

More breaking changes are coming soon, planned and unplanned. dApp developers have had notice for breaking changes of #8077 which will be rolled out soon, but not for these others. Users typically get no notice of breaking changes.

Unplanned breaking changes seem to happen often in modern software, even software from major companies. In npm, which many developers who develop alongside MetaMask are familiar with, a very intentional design decision was made to allow the user of a software package the freedom to choose exactly which version to use. Then if a package author releases a change with defects that accidentally break things, the user can easily revert back and continue with the previous utility value of the package while the package maintainers have some time to address the bug. Even standalone software in this space (e.g. geth) makes [previous versions](https://geth.ethereum.org/downloads/) available for download, allowing users to revert back as a quick workaround to new issues while a fix or better workaround can be developed.

Unless I'm missing something (which I hope I am), with MetaMask, there is exactly ONE version that users can access and install, and it's **automatically** updated to newer latest versions with **no option for user control.** If a MetaMask update breaks a dApp you want to use, oh well, you just have to wait, maybe weeks, for a fix to be developed, and just can't use the dApp in the meantime. If you are a developer yourself, you might be able to figure out a workaround or how to download MetaMask source, build it, and install it, overcoming various security warnings along the way. However, at least in our objectives as a developer ecosystem, **most MetaMask/dApp users are not developers**. MetaMask is nominally targeted at making dApps easier for non-developers to use.

If it hasn't happened already, this situation is just begging for a scammer to come in and take advantage. They can build an SEO-optimized site advertising older versions of MetaMask for easy download and install, and since no similar page is available from official developers, it would get traffic and use. The scammer's versions would likely work just as one would expect except some insidious side effects like siphoning off private keys to the scammer's server. **This is a security issue.** I could probably have a very profitable holiday break putting that together if this description isn't enough to lead the core team to take the Issue seriously, but I would much prefer this be resolved in an open way that helps build an ecosystem of trust and usability, even in the face of imperfect software developers.

In this issue, I propose two changes:
1. An option to download and install an older version of MetaMask, probably similar to the UI/UX around installing an [older version of Firefox](https://www.mozilla.org/en-US/firefox/releases/) (go to a Web page and select a release, click to download and install from there).
2. An option somewhere in the UI to make MetaMask not auto-update until after some specified date, maybe with buttons to push that off for a week or a month.

Part 2 is needed for part 1 to be effective, so that the older version selected in part 1 isn't immediately overwritten with the latest buggy version which motivated the user to pursue part 1. Part 2 might only be able to hold users at a version after that feature is added, but this should be as soon as possible; breaking changes are apparently going to keep coming despite the best effort of MetaMask's developers.

**Steps to reproduce**
Develop a dApp which uses MetaMask and put it out there for users, even a very small group of users.
Observe what a high percentage of breakage complaints are traced back to MetaMask defects.

**Expected behavior**
Ideally, better MetaMask testing before release and auto-update, but that should be created as a separate Issue, and would only reduce rather than completely obviate the need for this one.
This one is about allowing user control over which version of MetaMask they have installed, without requiring the user to build from source.

No files, tests, or entry points are identified in the issue. Begin by mapping how MetaMask distributes extension updates and exposes update settings, then determine the product and security constraints for selecting older releases and delaying updates. Done means users can safely choose a supported older version and defer automatic updates without immediately being overwritten.

Written by the indexing model from the issue text.