Rework inherent data client side

[bkchr]

This pr changes the inherent data system to be more flexible, especially the client side. Before this pr we only supported calling create_inherent_data and required that the inherent data was created without any context. We also shared the inherent data providers between block production and block import, while some inherents don't require any inherent data while being checked (at import).

So, the pr does the following high level changes:

• Split create_inherent_data into create_inherent_data_providers and create_inherent_data. While the former is async and thus, can use await.
• By default always pass the parent_hash to create_inherent_data_providers and add support for passing other arguments as well, while the caller can decide on which extra arguments to pass. This is especially useful for Cumulus that will for example also pass the relay_chain_hash a block will be build on.
• Move ProvideInherent to frame-support, because this is a FRAME specific trait and nothing generic.
• Reworked the inherent data providers to make the usage easier.
• Block building and block import is now separated, making it easier to decide which inherent data is required where.

polkadot companion: paritytech/polkadot#2845

[bkchr]

what was a bit weird to me is that now the InherentDataProvider is kind of a one-off thing, you just create it pre-filled with the data you want it to provide for a given block. My initial reaction when I read the PR description was: why wouldn't the parent hash be passed to InherentDataProvider instead of creating this new CreateInherentDataProviders trait?

I wanted to remove this "create InherentData and extract data later in the client again from the inherent data". I wanted to bake this into the type system to make it "more" obvious on what kind of inherent data providers are required by the "consensus" for example.

[bkchr]

bot merge

[ghost]

Waiting for commit status.