templates: add genesis config presets for minimal/solochain

[iulianbarbu]

Description

Closes #5790. Useful for starting nodes based on minimal/solochain when doing development or for testing omni node with less happy code paths. It is reusing the presets defined for the nodes chain specs.

Integration

Specifically useful for development/testing if generating chain-specs for minimal or solochain runtimes from templates directories.

Review Notes

Added genesis_config_presets modules for both minimal/solochain. I reused the presets defined in each node chain_spec module correspondingly.

PRDOC

Not sure who uses templates, maybe node devs and runtime devs at start of their learning journey, but happy to get some guidance on how to write the prdoc if needed.

Thinking out loud

I saw concerns around sharing functionality for such genesis config presets between the template chains. I think there might be a case for doing that, on the lines of this comment: #4739 (comment). I would add that parachains-common::genesis_config_heleper contains a few methods from those mentioned, but I am unsure if using it as a dependency for templates is correct. Feels like the comment suggests there should be a commons crate concerning just templates, which I agree with to some degree, if we assume cumulus needs might be driven in certain directions that are not relevant to templates and vice versa. However I am not so certain about this, so would welcome some thoughts, since I am seeing parachains-common being used already in a few runtime implementations: https://crates.io/crates/parachains-common/reverse_dependencies?page=3, so might be a good candidate already for the common logic.

[michalkucharczyk]

Regarding #4739 (comment)

Do we really need these functions? They look like some generic wrappers around sp-core/crypto types (or some related low level crate). Maybe they can be easily translated to some readable form. If not, maybe they should be moved there.

[bkontur]

Regarding #4739 (comment)

Do we really need these functions? They look like some generic wrappers around sp-core/crypto types (or some related low level crate). Maybe they can be easily translated to some readable form. If not, maybe they should be moved there.

@michalkucharczyk this is (partially) addressed here: #5705 and almost done here: #5804

[iulianbarbu]

I agree with @bkontur , maybe we can push on integrating the common methods somewhere more nicely and useful so that we can use them without duplication. Probably #5804 is the best candidate to do part of this change, if not the most important one.