Question: Inconsistent bloat bond specification

# Background
In the content and storage pallets there are two and 1 boat blonds, respectively, one for channels and one for videos, and all are mutable and are updateable by the lead

```Rust

/// content pallet

// Must be higher than ExistentialDeposit!
pub ChannelStateBloatBondValue get (fn channel_state_bloat_bond_value) config(): BalanceOf;

///The state bloat bond for the video (helps preventing the state bloat).
pub VideoStateBloatBondValue get (fn video_state_bloat_bond_value) config(): BalanceOf;

/// storage pallet

/// The state bloat bond for the data objects (helps preventing the state bloat).
pub DataObjectStateBloatBondValue get (fn data_object_state_bloat_bond_value) config(): BalanceOf;
```

This has a few problems

1. **Inconsistent:** I believe everywhere else, these are specified as runtime constants. Even if these are to be mutable, its not clear we should have them live in the pallet, and even if they should, perhaps we should make a systematic transition in a deliberate way across the runtime? Right now (when parameter value proposal is published that is), all other bloat bonds are being specified and computed in a reasonably involved way in the runtime configuration, this inconsistency has to be worked around.
1. **Risky:** While users do provide commitments to these costs when sending transactions, there is a very plausible risks that the actual end user will not pay much attention to it. Anything from user error to maliciousness can cause the lead to set a very bad value, which can lead to a very bad user experience.

# Question
Should we just drop this and go for the conventional pallet configuration approach?

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