GenesisBuild split

[michalkucharczyk]

This PR removes the storage building part from the GenesisBuild trait.

assimilate_storage and build_storage methods were moved to new GenesisBuildStorage trait which is implemented only for pallets GenesisConfig (and not RuntimeGenesisConfig). PalletGenesisConfig marker trait was added to facilitate this.

The rationale behind this is as follows: since #14306 GenesisBuild is implemented for RuntimeGenesisConfig. As the BuildStorage is also implemented for RuntimeGenesisConfig there was is duality now - RuntiemGenesisConfig had two bulid_storage implementations.

Trait split is implemented in 13d66fd, renaming in ad3b7df.

Step towards: paritytech/polkadot-sdk#25

cumulus companion: paritytech/cumulus#2720

[paritytech-cicd-pr]

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2961605

[gui1117]

I don't really understand, you but in another trait these method so you can implement GenesisBuild on RuntimeGenesisConfig ?

I'm not sure it worth it, why not create a new trait for RuntimeGenesisConfig specifically, GenesisBuild was meant for pallets and thus the signature is quite specific with <T, I>, I think it is better to keep traits and implementation of RuntimeGenesisConfig apart, no ?

Creating a new trait RuntimeGenesisBuild, maybe merged with BuildStorage should be better IMO

[gui1117]

Sorry for my bad suggestion, I agree what other said in the other PR, maybe this PR improve on the situation with a unique proper GenesisBuild, we could eventually get rid of the generics once with have decl_storage removed (is it already ?) and we can keep the other method for not breaking peoples tests in another trait or another way