Add parsing methods where missing.

[gnutix]

Fixes #68 by adding :

• YearWeek::parse('2023-W39');
• Year::parse('2023');
• DayOfWeek::parse('06');
• Month::parse('October');

I was not sure it made sense to add Year::parse(), because it's so close to Year::of((int) $string). But then I realized they do differ for dates (positive and negative) under 1000 / 100 / 10 because of the trailing zeroes :

Year::of((int) '-100'); // works
Year::of((int) '-0100'); // works, interpreted as -100 (PHP, right? :>)
Year::parse('-100'); // should throw an Exception, as the valid ISO is "-0100"
Year::parse('-0100'); // works

Same for DayOfWeek with its leading zero. I know DayOfMonth and Month will be converted into Enums in the next version (0.6), but I still think it doesn't hurt to add these methods on them in the meantime.

[gnutix]

Instant and Interval(Instant, Instant) don't have parse methods either. Not sure if it would make sense to add them or not. WDYT ?

[BenMorel]

Instant and Interval(Instant, Instant) don't have parse methods either. Not sure if it would make sense to add them or not. WDYT ?

If they're not needed at the moment, I would leave them for now.

[BenMorel]

@gnutix I'm OK with Year and YearWeek, but not Month and DayOfWeek for the reasons stated below!

[gnutix]

I'm OK with Year and YearWeek, but not Month and DayOfWeek for the reasons stated below!

Reverted. PR is ready for merge IMHO.

[BenMorel]

Thank you, @gnutix!

To iterate faster and avoid yet another feedback, I took the liberty to update your commits to rename data providers that didn't match the project's standards:

• providerParseInvalidValues providerParseInvalidYearThrowsException
• providerParseInvalidValues providerParseInvalidYearWeekThrowsException