Remove LegacyProvider streams

We have a set of redundant streams between contentscript.js and the provider in-place today to support websites and extensions that implemented their own providers rather than using our injected inpage.js provider. You can find these streams in our codebase by searching for the string LegacyProvider, which appears in a number of comments.

These are legacy streams because we renamed our streams to include the metamask- prefix, as a safeguard against these messages being intercepted and misinterpreted by other websites/extensions (See #8640 and #10179).

Extensions wanting to connect with us are forced to use their own provider because we cannot inject into extension pages.

Websites might want to use their own provider for a number of different reasons. Most prominently as a workaround for an incompatibility on Firefox between certain content security policies and our inpage script injection.

Websites and extensions have had the ability to use our newer streams to communicate since v8.1.7 (December 2020), but we have not done much yet to encourage migrating. Before we remove the legacy streams, we may want to consider doing these things:

• Add metrics to track usage of these legacy streams.
• Ensure our documentation is up-to-date for how websites and extensions can setup their own providers using our newer streams.
• Send out a notice of removal through all of our usual dev marketing channels (e.g. twitter, Medium, mailing list, etc.) to ensure as many people as possible are aware of the breakage.
• Reach out directly to any prominent websites/extensions that we notice are still using the legacy streams, and help them migrate.

Search the codebase for LegacyProvider references, beginning with the streams between contentscript.js and the injected inpage.js provider. Before implementation, review usage metrics, provider documentation, and migration outreach; done means legacy streams can be removed without leaving users of the older communication paths unsupported.