Partition duration for time structures

[JulStraus]

This is a first take on including partitions based on the duration of operational periods as outlined in #94. There are a few things to highlight:

The introduction of the PartitionDuration abstract type enables

• the introduction of time profiles indexed over the partition,
• the utilization of existing time profiles for indexing, and
• simplified indexing of variables (easier to identify the corresponding partition).

However, it requires the introduction of subtypes for all potential combinations. This is a bit annoying, but does not require to much work either.

There are still a few open questions:

1. Shall we allow for varying durations of the partitions? I personally think yes as a partition could be, e.g., 5 days and 2 days to differentiate between work week days and weekend days. The implementation should be straight forward.
2. The last partition can be in the current stage shorter than specified. The reason is that we do not know a priori a) how many partitions are available and how many time periods are in the last partition.

My plan is now to

1. incorporate profile indexing and
2. introduce all other subtypes that are required.

Important

I consider partitions only to be relevant for operational periods. The reason is that it does not make sense, at least in my opinion, to have partitions of operational scenarios. It could theoretically make sense for representative periods or strategic periods, but I think it is better to not allow for it at the current stage.

[JulStraus]

I added now support for most of the available time structures, excluding TwoLevelTree, SimpleTimes, and CalendarTimes. TwoLevelTree is something which I want to add in a different PR. In addition, I also want to add in a different PR the potential for specifying explicitly the minimum duration of each partition.