RFC: Aim to end provider injection entirely

Opening this issue to discuss the possibility of moving off an injected provider onto a fully `postMessage` based provider. This would not be a quick change, this would be a long transition, but it might be good to at least consider putting into eventual motion.

We usually talk about provider injection as a necessary evil for providing our API to websites, but really it was _to remain compatible with Mist_, back when the web3.js library was _the assumed interface_ for interacting with a Ðapp browser.

I’d like to highlight a specific downside of the provider injection (Related to #1515):
- It is the reason we have to request permission to read & modify information on all user websites.

Because of that permission, if MetaMask ever _were_ hacked (god forbid), the impact could actually go beyond the user’s accounts and impact their entire online presence. Banking, social media, etc.

Fortunately, as part of the EIP-1193 changes, we have moved many developers onto our increasingly popular [@metamask/detect-provider](https://www.npmjs.com/package/@metamask/detect-provider) module, as well as [eth-provider](https://github.com/floating/eth-provider), which could be used to allow even more easily migrating Ðapps onto alternative provider injection schemes (with a single non-breaking dependency update).

Would require some additional research on what it might look like to make our `inpage-provider` a developer-provided module, and if this limits the functionality or security of our interface in any way. This might also involve publishing an additional “compatibility extension” like our [legacy-web3 extension](https://chrome.google.com/webstore/detail/metamask-legacy-web3/dgoegggfhkapjphahmgihfgemkgecdgl).

Anyways, comments?

The issue names the inpage-provider, @metamask/detect-provider, eth-provider, and the legacy-web3 extension, but no specific files or tests. Start by mapping how the current injected provider reaches websites and how EIP-1193 is used. Done would require an agreed migration design, including compatibility, functionality, and security implications.

Written by the indexing model from the issue text.