Goverance set CRT constraints

List with proposed constraints that can be set by governance and the rationale, behind.
This is meant to be an extension from #4151 and to be referenced by the PR

### Revenue Split
- `timeline_max_duration`: this could prevent the CC from setting potentially too long staking period, I think this is more of a **usability** issue
- `timeline_min_duration`: no real attack vectors comes to mind, but I think this is more of a **usability** issue
- `split_percentage` this value ranges from `[x%, 100%]`. For a 100% amount the CC takes all the profits from the channel revenue (and I think this should be allowed). Like wise allowing `x` to be zero (user doesn't take any of the profits) shouldn't be a big problem **usability**
### Patronage
- `patronage_rate_min_value` patronage rate is a % value. Allowing it to be set to 0 is a way for the CC to limit the supply of CRT at a certain value (in case CC doesn't mint any other CRT), and I think it should be desirable from a **usability** point of view.
- `patronage_rate_max_value`: patronage represent a constant per block supply inflation rate that is destined to the CC. I think there's a real danger of the CC setting it to a particular high value and thus progressively reducing the % of supply owned by other CRT holders. **vulnerability** (in particular the CRT holders combined supply % will be reduced by `(1 + patronage_rate)^b` after `b` blocks)
### Sale & Vesting Schedules
- `cliff_amount`: this is the amount that a CRT sale buyer gets immediately when vested. Setting it to 100% is equivalent to not having any vesting ongoing. I don't see any particular problem with low values either **usability**
- `min_crt_amount_issued_in_a_sale`: I just think that it doesn't makes sense to issue a sale with `0` tokens **usability**
- `sale_max_price`: computing `price * amount_bought` can result in a overflow and the buyer will see its sale purchase resulting in a error. So maybe some common sense checks should be provided (but maybe on the front end). Besides that I don't see any problem **usability**
- `sale_min_price`: I think this can be zero, allowing the CC to give away token for free if desired **usability** tokens are not minted in a sale but just distributed in exchange for JOYs
- `sale_duration`: I think this is a pure #usability thing. Clearly it doesn't makes sense for a sale to be 0,1,2, blocks in duration. And a user that takes more than 6sec (avg block production time) to click the buy button can miss the opportunity.
- `number_of_upcoming_sale_updates`: How would users react if the CC will repeatedly start to delay the sale start? It makes sense to limit this from a **usability** POV
- `cap_per_member`: It should makes sense to have a maximum cap (otherwise the no cap option would have been preferrable). Setting a cap to `0` however would exclude a user from a sale, so I think that a `min/max_cap_amount` should be set by governance to provide better **usability**
- we should set an absolute value for the `transfer_destinations` max amount, otherwise unbounded input vulnerabilities are possible to exploit ( **vulnerability** )
### Token Issuance
- `max_amount_of_token_issued_in_a_period`: this makes sense to avoid low-quality projects (same rationale for limiting NFT applies here) **usability** . I think that only allowed verified channels (see [channel verification](https://github.com/Joystream/joystream/issues/4487)) to issue CRT is a way to ensure that only quality tokens are issued.
### AMM
- see [Consideration On Amm parameters](https://github.com/Joystream/joystream/issues/4488)
- `amm_sell/buy_tx_fee_pct` are governance controlled parameters

All of the above parameters can be set by the governance through proposals