Rework activity limits code

[alexdewar]

Description

I'm on leave this afternoon and it's unlikely that I'll be back until after paternity leave at this point, so I thought I'd open a PR for this, even though it's broken 😢. The example models now all fail to run because there is unmet demand and I'm not sure why: the constraints should now be less restrictive!

I'm just going to leave this here in draft. Feel free to fix it up and merge or you can wait until I'll I'm back. I think that #957 is a pretty important bug to fix and this is a fairly big refactor, so if we leave it there will be merge conflicts. On the other hand, fixing merge conflicts might be the right level of task for my sleep-deprived brain when I get back 😆, so I don't mind if you'd rather not clean up my mess.

I figured that it wouldn't be too painful to refactor things to fix up #957, but I was wrong. We rely on activity limits being specified as time slices all over the place (e.g. in investment.rs and graph.rs for validation). It actually ended up being easier to do #958 and #743 at the same time while I was reworking things.

As part of this, I changed the ProcessActivityLimitsMap so that the limits aren't pre-multiplied by duration. (I made this change beforehand and things still worked at this point.) I created a new PerYear type to represent this, which means that Asset::get_activity_limits() returns an ActivityPerYear value (for example). To use it, you obviously need to multiply by a duration later on.

I think it's nearly there. The problem might be to do with the way I'm doing the activity constraints now. For one thing, there now should be an additional requirement that the activity for each individual time slice shouldn't exceed the maximum allowable for that time slice (otherwise the whole year's activity could happen in one time slice). I don't think adding that will fix things by itself though.

Fixes #957. Closes #958. Closes #743.

Type of change

• Bug fix (non-breaking change to fix an issue)
• New feature (non-breaking change to add functionality)
• Refactoring (non-breaking, non-functional change to improve maintainability)
• Optimization (non-breaking change to speed up the code)
• Breaking change (whatever its nature)
• Documentation (improve or add documentation)

Key checklist

• All tests pass: $ cargo test
• The documentation builds and looks OK: $ cargo doc

Further checks

• Code is commented, particularly in hard-to-understand areas
• Tests added that prove fix is effective or that feature works