Also do some internal renaming from Tally to Taho in a few places that
aren't externally-facing.

Rather than try to intercept and swap out or filter provider lists, we
now always wrap any provider that looks like MetaMask (right now we
look at isMetaMask + make sure there are no is* properties on the
provider) with a proxy. That proxy always forwards requests to Taho if
the user has set Taho as default, meaning they've explicitly opted into
replacing MetaMask with Taho.

When Taho is set as default, the wallet router now reports isMetaMask =
true, while the Taho provider always reports isMetaMask = false. This
allows dApps that support Taho as a first-class provider to see it
as itself. In general the Taho provider is less concerned with
masquerading as MetaMask, leaving that to the MetaMask wrapper proxy and
the wallet router.

Additionally, the wrapper only routes an allowlist of methods to Taho to
minimize divergence of behavior from MetaMask when it is installed.

Some frameworks, like Wagmi, always display the first item in the
providers list as the injected/browser wallet. Some sites that do this
also don't check the providers list for other wallets, so that even if
MetaMask is in the providers list, the MetaMask button shown to the user
doesn't actually bring up MetaMask, instead showing the MetaMask mobile
connection option.

To get around this, the providers list is now rearranged when Taho is
switched to or from default. When it's set as default, it is placed at
the front of the providers list; when it's set as not default, the
previous provider it replaced is set as first.

For the specific case where Taho is set as default but MetaMask does not
seem to be installed, we now inject a MetaMask-alike in the providers
list to allow dApps that only look for MetaMask to work correctly.

When Taho is cleared from being default, the MetaMask-alike is removed
and the fact that MetaMask is not installed is left as-is for the dApp
to detect normally.

While no observed behaviors broke on this, the existing invocation
strategy could lead to failure if provider-private variables were being
accessed, due to a shift in the `this` reference.

Some dApps were sending an extraneous parameter up front as if they were
expecting to call wallet_requestPermissions. We now discard that
parameter when attaching the dApp title and favicon in the content
script.

wallet_addEthereumChain remains unchanged.