Undefined `start_year`/`end_year` should mean "no limit", rather than first/last milestone year

[tsmbland]

If a user leaves the start_year for a process empty, I think they would reasonably expect that there should be no lower limit on the installation year for that process.

However, currently, if the user tried to add an existing asset from before the first milestone year, they would get an error like Process GASDRV does not operate in the year 2010

This is because we automatically use the first milestone year (in this case 2020) as the start_year. To fix this, the user would have to manually set the start year to 2010 or earlier (although it's not really clear from the error message that this is what they have to do).

Ideally, if the user leaves start_year empty we should allow existing assets from before the first milestone year, with no lower limit. (I guess it's probably unlikely that users will want to install something in 400BC, so we could reasonably impose a lower limit if we need!)

Practically, I'm not sure how we do this because we store a vec of years for each process rather than a range, and we don't want to have to store all years in the vec, but something to think about.

Linking #845 as well as these may be related

[alexdewar]

Good point. I think the solution is probably to store the (optional) start and end years in Process instead. That would mean in some contexts we'd additionally have to check whether a year was a milestone year, but we may want to drop this restriction anyway (see: #770 (comment))

[alexdewar]

I think end_year should also default to no limit (==u32::MAX).

Note that this is on hold because if we implement it before #874 we will end up with thousands of copies of process maps in memory (or billions if we also remove the limit on end_year 🙃).