Add eth.BlockSpecifier for EIP-1898 Support

[ryanschneider]

Now that Infura is predominately using geth 1.9.x for our backend nodes, I'd like to consider exposing EIP-1898 support, and adding it here seems like a good first step.

I'm picturing something like:

type Tag string //also update eth.BlockNumberOrTag to use this

type BlockSpecifier struct {
  Number *Quantity 
  Tag *Tag
  Hash *Hash
  RequireCanonical *bool
  Raw bool
}

And custom JSON (un)marshal routines that can handle the various cases:

• raw Quantity or Hash
• tags ("latest", "pending", etc.)
• the JSON format in the EIP itself

.Raw can be used when constructing a BlockSpecifier in code to control how it'll be marshaled, if true then the specifier would be marshaled as a simple string instead of a JSON object (e.g. { Tag: Tag("latest") } would be just "latest" and not { "blockNumber": "latest" }.

[meronym]

@ryanschneider are we concerned about preserving backwards compatibility?

E.g. changing the definition of BlockNumberOrTag from

type BlockNumberOrTag struct {
	number Quantity
	tag    string
}

to

type BlockNumberOrTag struct {
	number Quantity
	tag    Tag
}

might break existing code (outside go-ethlibs)?

[ryanschneider]

We're generally ok with breaking compatibility in this module for now, especially if it makes the module itself easier to use, so at this point I still consider this module "v0" with respect to compatibility promises.

For example I'd really like to implement #17 and move away from defining per-RPC methods on node.Client; it'd be a sizable change to the interface to start, but would mean that new RPCs can be added going forward without any changes to implementers of the Client interface in other packages.

[meronym]

Merged EIP-1898 Support into master.