[Bug] - PRJ period startdates not treated by iMOD Python as in iMOD5

Bug description
We were struggling quite a lot with how to handle the period startdates of the projectfile in python, given that the years entered are usually outside the nanosecond range. We resorted to just ignoring the year that is entered, and replacing it with 1899, which is outside iMOD5's calendar range, so doesn't result in conflicts with regular transient packages.

However, this is not how iMOD5 treats period startdates, from the manual:

Startdate of the given period. A PERIOD repeats until another time
definition is more close to the current timestep. Specify the date as
dd-mm-yyyyhh:mm:ss, so to specify midnight for the 6th of September
it needs to be entered as: 06-09-2018 00:00:00. If this need to applied
each year the notation is 06-09-0000 00:00:00 which means that it applies 
for the 6th of September no matter what year. Another example for
a repition per 6 hours is 00-00-0000 06:00:00, in this case for each day,
from 6am this packages applies.

I don't think we need to support the per 6 hour stuff, as I've never seen this in the wild. However, supporting the year 0000 needs to be done. Unfortunately, datetime.strptime() doesn't support the year 0, at minimum it requires the year 1, which is quite surprising.

Furthermore, in the iMOD importer, I only support a hardcoded "summer" and "winter" period label, however, I've seen this being used in IBRAHYM:

Periods
winter1
01-01-0000 00:00:00
summer
01-04-0000 00:00:00
winter2
01-10-0000 00:00:00

Apparently, iMOD5 doesn't properly forward winter2, so they created this workaround. Not sure whether we should support this, it can increase code complexity quite a lot. At least we should document this as a Known issue.

Start by tracing the iMOD importer’s period parsing and datetime handling, then compare its behavior with the documented iMOD5 rules for year 0000. Done means year-0000 period start dates are handled correctly and the winter2 behavior is addressed or documented as a known issue.