Refactored OCPP1.6 Composite Schedule calculation

[Pietfried]

Describe your changes

Refactor of OCPP1.6 Composite Schedule calculation using the same approach that was introduced for OCPP2.x by this PR: #943

The reason for the refactoring is to change the composite schedule calculation for connectorId 0.

The CS has multiple EVSEs
It has a ChargePointMaxProfile with a limit of 32A
It has a TxDefaultProfile with a limit of 10A installed on evseId 0 (so this counts for all EVSEs)
Getting a composite schedule for evseId 0 should then calculate the sum of the schedules for each evse and combine that with the ChargePointMaxProfile. This should result in a limit in the composite schedule of 20A.

Summary of the changes:

• Introduced IntermediatePeriod and IntermediateProfile for OCPP1.6
• Added profile calculations and merging functions to v16/profile
• Support for stackLevel and periodTransformed for EnhancedChargingSchedulePeriods was kept
• Copied test cases for for composite schedule calculation from OCPP2.0.1 and adapted to OCPP1.6

1. Note on changed test cases
The new approach does not add numberPhases to the composite period in case the original profiles did not have a numberPhases property either. This is different to the approach that was present before and had to be changed throughout the test cases. In addition, the stackLevel calculation changed in a way that also the stackLevel of profiles with purpose ChargePointMaxProfile are considered if those provide the lowest limit while merging the periods.

2. Note on stackLevel and periodTransformed support:
I tried to keep these properties part of the EnhancedChargingSchedulePeriod although the new approach leads to some ambigouity in certain cases.

With the new approach, a composite schedule period for connectorId 0 can be composed by the sum of periods from multiple profiles (e.g. multiple different TxDefaultProfiles). These profiles may have different stackLevel values, which makes it impossible to define a explicit stackLevel for the composite period.

For the same reason, periodTransformed can also not be clearly defined for connectorId 0, since the composite period may be composed by periods with different chargingRateUnits.

3. Note on code duplication
Quite some code and tests have been copied from the v2 implementation. I see quite some potential for a subsequent refactor, but the PR is already quite large. Also, the special handling of the EnhancedChargingProfile as well as mostly no common type definitions for v16 and v2 make it more difficult.

Issue ticket number and link

Adjustment of everest-core test cases (see 1. Note): EVerest/everest-core#1177

Checklist before requesting a review

• I have performed a self-review of my code
• I have made corresponding changes to the documentation
• If OCPP 2.0.1 or OCPP2.1: I have updated the OCPP 2.x status document
• I read the contribution documentation and made sure that my changes meet its requirements