Minimise boilerplate and repeated code between system parachain runtimes using derive_impl

[seadanda]

The system parachains contain a lot of common pallets which are configured basically the same, on top of which the actual business logic of the chain is built. Ideally the system parachain runtime code should be little more than is contained in the diff between them. We can approach this with better use of common types and default configs, but stopping short of a chain of new macros which obfuscate the configurations.

The aim of this proposal is that a DefaultConfig for all pallets used commonly in system parachains could be defined for the SystemParachainDefaultConfig struct, and then used across all testnet runtimes. This will hopefully reduce the maintenance burden of adding new configurations which are unlikely to change across most system parachains, and will also decrease the copy-pasta across parachain code.

I propose that we add a default_configs module common to all testnets (POC for frame_system in #4056), and a separate default_configs module common to production system chains to the polkadot-fellows/runtimes repo since the default configs for the runtimes repo should be contained directly in the fellowship and not imported from the sdk.

This default_configs should live in
paritytech/polkadot-sdk: cumulus/parachains/runtimes/constants
paritytech/polkadot-sdk: system-parachains/constants

And define a baseline to be shared between all parachains across all networks for the following pallets:

• frame_system
• cumulus_pallet_parachain_system
• pallet_timestamp
• parachain_info
• pallet_balances
• pallet_transaction_payment
• pallet_authorship
• pallet_collator_selection
• pallet_session
• pallet_aura
• cumulus_pallet_aura_ext
• cumulus_pallet_xcmp_queue
• pallet_xcm
• cumulus_pallet_xcm
• pallet_message_queue
• pallet_utility
• pallet_multisig
• pallet_proxy

These baselines can be built on for each type of system parachain: e.g. asset-hubs/common, coretime/common etc.
These should be used to configure the pallets specific to those system parachains, and then each runtime should override the network-specific configurations that differ between Polkadot and Kusama.

With these two layers of constants (or maybe better named common) crates the types that are repeatedly defined through the runtimes can be shared more effectively.

Something totally analagous could be achieved for the relay chains by following the same steps.

As Muharem suggested here we could have a baseline totally general configuration that applies to both relay and system parachains, but we would still need to have the second "layer" of DefaultConfigs inheriting from the base ones which differ for relays and parachains.

The power of this with system parachains is that for a given network there are many repeated configurations through all of that network's system parachains, and for a given system parachain there are repeated configurations between networks. We should be able to remove at least one dimension of this repetition through DefaultConfigs.

In addition some unneccessary specific naming should be made general (e.g. DotLocation->TokenLocation) and reordering of configs and parameter definitions (commonly used first, followed by the pallets specific to the given type of system parachain) would take us closer to a minimal diff between parachains.