Reorganizing parameters: mutable, configurable and unified

# Background
We have a large number of literal constants across

* the runtime
* the node
* pallets

littered across the code base which impact business logic. To be clear, by this I mean a literal value in the Rust code which itself can only be changed or removed with a runtime upgrade or a fresh network. I am here not talking purely about numerical constants, although they constitute the majority, I really mean _any_ literal value. There are a few problems with them being organised this way.

* **Disorganised:** They are scattered all over the final runtime in a way which makes it quite difficult to understand what the full set of exogenous parameters that shape the runtime functioning are.
* **Not configurable:** Often we may want to easily build versions of a pallet with different values, for example for specific testing environments, or even just for unit testing purposes. **This is currently really bad, with duplicate inlined specifications for staging and production environments** :cry: :cry: :cry:
* **Static:** Changing any value in a running system requires a runtime upgrade, which a more risky process, not only technically, but also because its harder for a non-technical person to adjudicate exactly whether a new final runtime WASM file corresponds exactly to a desired parameter change, as issues pertaining to build configurations and Rust have to be carefully reviewed.
* **Documentation:** When each pallet author or subsequent contributor makes one off constants here and there, its harder to enforce a rigorous and expansive documentation norm for such values.

# Proposal
* Remove every literal value in all pallets, and turn them into module trait values that can be specified at runtime composition, and where it should be possible for the value to be dynamic.
* Remove _all_ literal constants in the runtime **which can be changed safely in production without migration!!!**, and replace with mutable storage values in a new pallet, called `parameters`.
* Make sure to introduce a `Root` origin get/set pallet method which allows the proposal system to read/write value.
* make all such pallet storage values configurable, so that it's practical to build the node to run under very different circumstances.
* Somehow make _all_ literal constants in the runtime which are not safely updatable in production at least configurable at compile time in a type safe way.

A very attractive part of making parameter values configurable is that for some it may be important to harmonize or synchronize the way they are set with other values in `GenesisConfig` for some pallet, and making all of them originate from the chain spec building process makes that much easier to enforce properly.

┆Issue is synchronized with this [Asana task](https://app.asana.com/0/1201958687417145/1202881914472612) by [Unito](https://www.unito.io)