Proposal: use Interfaces for Singer and Provider instead of abstract classes

[pkieltyka]

hey @ricmoo -- nice work on v5 of ethers, great to see the project iterate and evolve so nicely.

I think one thing that could make the ethers api more flexible and extensible is to use interface types to define the core Provider and Signer methods. As in v4, and I see in v5 too, there is a class chain of inheritance that defines a base Provider or Signer, and specific variants.

One thing that would be nice is to be able to do have subproviders and chaining for various methods, which is far easier when objects implement against an interface instead of having to be a subclass. Ideally, both could coexist and the receiver types within the methods would be based on the interface types, and inheritance could be used to split up variants, but just full-filling the interface. Then chaining methods / subproviders would be trivial to include.

One approach is to drop the abstract provider and signer, and instead turn those into and interface type. Then the BaseProvider and BaseSigner could implement any core method implementations that would be used by all other providers in the library.

Alternatively, rename "Provider" to "AbstractProvider" and then define Provider as interface type which AbstractProvider implements, and similarly for Signer primitive types. Then throughout the project use Provider as the receiver type where a Provider is expected. This is probably smallest structural change.

[ricmoo]

I like the ideas and will investigate this more for v6. I'm hoping to release v5 next week, so I think the larger changes are locked in for now. :)