1193: Make spec availability-agnostic

[rekmarks]

File: https://github.com/rekmarks/EIPs/blob/1193-availability/EIPS/eip-1193.md

For the purpose of this PR, let's define the problem of how to expose the Provider API as "availability" or "the availability problem."

Per this comment by @alcuadrado, one of the concerns from the 1193 meeting at Devcon 5 was:

1. EIP-1193 began as a spec on how to expose a provider in a dapp browser, but mutated into specifying its interface. It still depends on EIPs related to browser-specific stuff.
2. The way a provider is exposed (i.e. window.ethereum) only supports a single provider. This is in conflict with users installing multiple wallet extensions, and may be problematic with a multi-chain future.

Meanwhile, the proposed solution was:

1. EIP-1193 will only focus on the provider's interface. How to expose in browser environments will be part of another document, possibly an RFC. Any dependency on browser-specific EIPs will be removed.
2. As this EIP won't dictate how to expose the provider, this item is outside of its scope.

The goal of stripping all (normative) availability-related language was never fully realized, and recently merged PRs (#2577, #2586) in fact introduced more such language.

This PR makes the spec completely availability-agnostic, while including a non-normative section noting that window.ethereum is, by convention, the de facto standard for exposing the Provider API. Said section notes some limitations of this convention, for the benefit of Provider implementers, dapp developers, and future authors of future EIPs.

Code examples remain unchanged, and use the window.ethereum convention (although note that it is merely a convention).

[rekmarks]

cc: @adrianmcli @ryanio

[eip-automerger]

Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):

• EIP 1193 requires approval from one of (@MaiaVictor, @frozeman, @marcgarreau, @ryanio)

[adrianmcli]

The diff looks good to me! Nice work @rekmarks

[frozeman]

I like it to be generic. Though we should talk about how a multi EVM chain future can be possible with this provider. E.g. ethereum.chainX.request(), or ethereum.request('chainIDX', 'method', [params])

[rekmarks]

@frozeman I was thinking about how to change the request method signature to enable the targeting of a specific chain, or even another protocol entirely.

That'd be a different PR, of course, but the two things that come to mind are:

1. Just add a third config param, like so:

request(method: string, params: Object | Array, config: Object): Promise<unknown>

2. Change/overload the signature such that it can be passed a single object param:

interface RequestArgs {
  method: string;
  params: Array | Object;
  chainId?: string;
  ...otherStuff: Array<any>;
}

request(args: RequestArgs): Promise<unknown>