Refactor for Dapp Provider

The provider we have been using up to now should be considered as legacy now; it's not worth spending much more time on it.

MetaMask and other providers have changed the way the provider is injected:

https://medium.com/metamask/no-longer-injecting-web3-js-4a899ad6e59e

It's not as big a change as it first appears in the article.

Can you do a refactor of the full injector logic along the same lines as the Trust web3 provider which is closer to the MetaMask code than our current provider. Feel free to use as much of the Trust provider as you need to - it works fine. It would be interesting to know the differences between this provider and the reference MM provider here: https://github.com/MetaMask/providers

Refer to the Trust example here:

https://github.com/trustwallet/trust-web3-provider

We should create our own updated provider repo; which may be a fork of this repo initially. I think they produce a minified js from a few components; themselves slightly out of date as of writing (no support for EIP3326).

In comparing the source code for this provider it's quite a bit cleaner and easier to maintain than our implementation due to the different model:- each hooked function goes via the same 'postMessage' call with the first argument is the function itself. So, only a single @JavascriptInterface is required, then a switch table can direct the call to the required function.

Currently we hook each function separately in the provider, then drive it through another function in the init code (init.js) and finally into a different @JavascriptInterface for each function. So it makes adding new functions quite labour intensive.

The goal is to modernise the provider in line with the MM update.

You will need to add EIP3326 support as there are dapps that expect this function that don't work without it (eg Pegaxies: https://pegaxy.io)

We will create an AC table with existing Dapp support to determine if the update is at least as good as the current update (after the Dapp provider fix goes in). It is expected in the long run to be as compatible as MM with dapps.