Capacity growth and total capacity constraints

In MUSE1, users can provide three constraints on investments
- addition limits: amount of added capacity in a year
- growth limits: percentage change in capacity per year (e.g 0.1 -> max 10% growth allowed)
- total capacity limits: a hard upper limit on total capacity

See MUSE1 docs here: https://muse-os.readthedocs.io/en/latest/inputs/technodata.html (under "Capacity constraints"). That goes through it in way more detail, with examples.

In MUSE2, we currently have addition constraints implemented, but not the other two. We need to find a way to get the other two constraints in there. Rough idea:
- add two more columns to `process_investment_constraints.csv`
- sensible validation (e.g. not negative)
- missing values should be allowed -> implies no limit (just like MUSE1)
- store these as extra fields in `ProcessInvestmentConstraint`. Note that growth limits will need to be pre-scaled at load time based on the gap between milestone years, just like we currently do for addition limits.
- modify `get_addition_limit` to solve all the maths to get an overall addition limit, taking into account the three different constraints
- This addition limit can then be used downstream just as it currently is (i.e. scaled by the `commodity_portion`*, returned from `max_installable_capacity`, etc.)

The main challenge is that calculating an overall addition limit from the provided growth limits and total capacity limits requires knowledge of the _current_ capacity, so we'll need to find a way to make `max_installable_capacity` and `get_addition_limit` aware of this.

Quite a lot to do, so may be best to break this into multiple PRs (e.g. one for input loading and validation, one for implementation)

\* It may actually be more correct to gather the capacity owned by each agent first, and calculate growth limits from this, rather than summing all capacity, calculating an overall limit, then splitting this between agents according to their commodity portion. That would probably require more substantial changes to the code, but could be considered as a future improvement.