Safe bloat bond price specification

# Background
An analysis was conducted of how this is done currently in our code base, as inherited from Substrate/Polkadot/Kusama: https://github.com/Joystream/joystream/issues/4195

The purpose of this issue is to propose how to implement the conclusion found therein.

# Proposal

## Our pallets

For pallets that **we have authored:**

* Each pallet no longer has each bloat price as a configurable, as this requires exporting lots of details about internal types out into the runtime for safe price computation. Instead, each pallet just asks for two prices which can be configured
* `FixedBloatBondPrice: Balance`: the fixed price of any mapping in storage, regardless of size.
* `PerByteBloatBondPrice: Balance`: the per byte price of a mapping in storage, as function of size.
In the future these can be configured as storage values, so that governance can update them to reflect changes in fiat price of $JOY.
* The pallet internally computes the required bloat bond to be charged for different maps by simply using max length of internal type representations which are automatically derived from types, not hard coded, so you do something like `ChannelRecord::length()`.
* The can compute the full final price by for example using some `deposit`function we can put into `common` module, which has the basic functional form as the one we use today, but also accepts prices as inputs, that way each pallet does not need to redefine the same deposit logic over and over. This function also can ensure that bloat bond is greater than the existential deposit, as needed in many cases, so that we automatically address https://github.com/Joystream/joystream/issues/3505. For example `pub const fn deposit(items: u32, item_price: Balance, bytes: u32, byte_price: Balance, at_least_existential_deposit: Boolean) -> Balance`.

Observe that in this proposal, we no longer specify prices for multiple individual bloat bonds, like video vs channel, they all are computed the same way, which is in the end what Kusama and Polkadot do. Now it is possible that perhaps in the future we want to artificially increase or decrease the price of different maps, but this is easy to overlay as a new argument to `deposit` or something.

## Third party pallets

For pallets that **we have not authored**, we do not want to fork them, so the best we can do is to avoid using just random literal numbers, we can instead compute object sizes based on types available. So for example if there is a storage map `Foo` with type `K->V`, then declare a constant `pub const FooMappingSize = K::length() + V::length()`, so as to keep everything more clear and in synch with implementation.

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