If occurred time is not initialised in BELGIUM_MAXIMUM_DEMAND_13_MONTHS default to timestamp of the month

[ejpalacios]

For the entry BELGIUM_MAXIMUM_DEMAND_13_MONTHS , if there is no consumption at all during a given month, the value of the occurred field in that given month will have an invalid timestamp. Something like: 632525252525W.

See below the snipped of a telegram containing this type of reading. The change suggested in this PR is to default to the timestamp of the month.

0-0:98.1.0(9)(1-0:1.6.0)(1-0:1.6.0)(230101000000W)(632525252525W)(00.000*kW)(230201000000W)(632525252525W)(00.000*kW)(230301000000W)(632525252525W)(00.000*kW)(230401000000S)(230316134500W)(00.047*kW)(230601000000S)(230524154500S)(00.018*k
W)(230701000000S)(230626120000S)(00.008*kW)(230801000000S)(632525252525W)(00.000*kW)(230901000000S)(632525252525W)(00.000*kW)(231001000000S)(632525252525W)(00.000*kW)

It might not be something very common, but it can happen with meters that have been installed but not connected to end consumption point yet.

[dupondje]

Might want to prefer #143 ? As this will hide the value is not set by just setting a default value.
I might prefer to just handle the fact that the value can be None.

[jbouwh]

@dupondje why would you want to fill in defaults. I think this simple fix works too.

@ejpalacios I am missing tests with this PR

[dupondje]

@dupondje why would you want to fill in defaults. I think this simple fix works too.

@jbouwh : this PR adds a default value if the occured timestamp can't be parsed. It might be cleaner to just handle the fact the value can be invalid and set it to None like #143 does.
Cause then the client of the library does know the value was non-existent/invalid instead of some default/current timestamp value.

[ejpalacios]

@dupondje your approach makes more sense