Beta distribution

This is a tracking issue for all of the tasks relating to creating a beta distribution of the extension. Some of these points will be adjusted or expanded as we further refine our plans.

- [x] Design beta release
* Design changes include: new logo, new warnings during onboarding, possibly warnings elsewhere as well
- [x] Add build flag for "beta" build which triggers different icon/branding, and warning messages
* Any static MetaMask logo images (e.g. on the Home page and logic page, during onboarding, the favicon) should be updated to use a beta MetaMask logo
* We should display a warning upon install to ensure users understand the risks
* We should consider displaying warnings elsewhere in the application as well (to be determined)
* This flag should require that a beta version number is specified
* This flag should ensure the Sentry environment used is "beta"
- [ ] Trigger a "beta" build when a non-hotfix release candidate is ready to publish
* Our release automation scripts should recognize this scenario and trigger a "beta" build rather than a production build, using the beta release version (which is of the format `X.Y.Z-beta.N`, where `X.Y.Z` will be the final production version after it passes beta, and `N` is the beta build number, starting at 0)
- [ ] Setup a process for creating a new release candidate to address problems found during the beta
* This should increment the beta build number, and produce a new beta build when approved
- [ ] Setup a process for building a production release, once the beta period has ended and we have a build that we are confident in
* This should be a process similar to the one we use for creating release candidates, so that we can have a final QA pass.
- [x] Write extension store description
- [x] Add page to website for beta
* This should be our authoritative link to the beta distributions for each browser
* This should explain the intended usage, including any relevant warnings and disclaimers
- [x] Create marketing campaign to explain and promote the beta distribution
- [x] Ensure the support form has an option for the extension beta

Non-blocking goals:
- [ ] Beta-specific migrations
* This might be useful if we want to make state changes during the beta that don't affect production users
* This could be used to wipe state completely if we make a horrendous mistake, or to undo or wipe out specific things.
- [ ] Consider including Flask description/preview in website update and marketing campaigns
* Since we're hoping to introduce Flask in the next few months, explaining it now might offset confusion from introducing a third distribution in such a short time frame.