As noted, build year aggregation as in #1056 doesn't work as implemented when combined with time series segmentation because the segmentation could (and often is) different for different planning horizons.

Changes proposed in this Pull Request

The present PR splits time aggregation off into its own rule which is run only once for all planning horizons. This rule is what constructs the new subset of snapshots and their weights; the aggregation of time-dependent data is performed in prepare_sector_network.py

I thought this isn't a terrible thing even independently of build year aggregation; there might be other times when you want to directly compare the same network at different planning horizons snapshot-to-snapshot. I also imagine it might be a little easier to implement new time aggregation features as this step is now a little more isolated and easier to comprehend.

Do let me know if this seems like a reasonable idea or not, or if anyone could imagine a different but better way of achieving the same objective.

Checklist

• I tested my contribution locally and it seems to work fine.
• Code and workflow changes are sufficiently documented.
• Changed dependencies are added to envs/environment.yaml.
• Changes in configuration options are added in all of config.default.yaml.
• Changes in configuration options are also documented in doc/configtables/*.csv.
• A release note doc/release_notes.rst is added.