Configurable extrinsic `Extra`

[ascjones]

From #294

Allow user to define default Extra implementation for additional signed data, or auto-generate from the metadata. At the moment this is hardcoded in the macro generated code.

subxt/codegen/src/api/mod.rs

Line 245 in fc30e90

type Extra = ::subxt::DefaultExtra<DefaultConfig>;

Replace hardcoded default extensions, these could be generated from the metadata, or the user could supply their own implementations.

Slight wrinkle is that a couple of the hardcoded ones require some data we need to supply up front, notably nonce and genesis hash. And currently the supplying of those values is done by the client, so need to come up with some solution there. It's probably safe to assume that most/all chains will support those two extensions.

Rel #330

[sander2]

I was thinking a little bit on how this could be implemented. We could maybe keep the DefaultExtra struct hardcoded, but move its SignedExtra implementation into codegen. We can generate the type used for DefaultExtra::Extra based on the metadata; just need to create a tuple from the items in extrinsic::signed_extensions. We can then require the user to implement SignedExtension for each type in that tuple.

This should work, but has the downside that it requires the user to provide quite some boilerplate code. If we can assume that the user never needs to overwrite e.g. CheckNonce, CheckMortality, etc, we can include their implementation in the codegen. If we want to go a step further and provide default implementations but allow the user to overwrite the defaults, then we'll need to generate traits for each extension instead.

What do you think?