Add {sector_opts} wildcard to snapshot_weightings output

[koen-vg]

I can't believe that I missed this, but this restores the functionality of time-aggregation wildcards for sector-coupled networks.

Checklist

• I tested my contribution locally and it works as intended.
• Code and workflow changes are sufficiently documented.
• Changed dependencies are added to envs/environment.yaml.
• Changes in configuration options are added in config/config.default.yaml.
• Changes in configuration options are documented in doc/configtables/*.csv.
• Sources of newly added data are documented in doc/data_sources.rst.
• A release note doc/release_notes.rst is added.

[fneum]

I can't believe that it wasn't missed so far :)

[fneum]

Ah, I think it was done on purpose so that all {sector_opts} scenarios would share the same clustering (354fffe, #1065).

I think this should supersede the functionality to set the clustering by wildcard. Not sure, @koen-vg, but maybe we should revert this PR.

[koen-vg]

Ah, so the original motivation I had for doing it this way was to ensure that time-aggregation would be constant over planning horizons, but not necessarily sector-opts in general. I could maybe imagine some cases where you would want time-aggregation to be the same across sector-opts, but I actually haven't encountered those cases. Are there any specific instances where this would be useful?

It is also worth mentioning that adding the {sector_opts} wildcard to the time-aggregation rule doesn't mean that the sector-opts are actually used in the time-aggregation. Adding this wildcard means that the configuration is updated with the given options, but the only place that the configuration is used in time_aggregation.py is to retrieve the temporal resolution! Apart from that, time aggregation only depends on the input network (and optionally heat demand and solar thermal time series), which is independent of the sector-opts. So unless I'm quite mistaken, it is actually the case that the time aggregation is guaranteed to be the same across sector-opts anyway?

Slightly confusingly, the only utility of having the {sector_opts} wildcard in there is so that the update_config_from_wildcards function is run to update the time resolution config, and this is run from inside the config_provider function when the time_resolution param is set under the time_aggregation rule.

And I have to say that I personally set the time-resolution using the sector-opts wildcard quite often, so I would be personally a little sad to lose this functionality :)