Fix some recurrence evaluation issues

[minichma]

This PR fixes the following issues listed in #618:

DTSTART:20141006T090000, RRULE:FREQ=WEEKLY;INTERVAL=1;COUNT=2;BYDAY=MO;

The trailing semicolon caused an exception and is now ignored. Additionally handling of illegal rule parts having a number of = chars that is different from 1. In such a case an ArgumentException is raised, which seems to be in line with other exceptions raised in that class but could be discussed.

RRULE:FREQ=WEEKLY;UNTIL=20170127T000000Z;WKST=MO;BYDAY=SU,TU,TH;INTERVAL=2

The start of the week was not considered correctly.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

@@         Coverage Diff         @@
##           main   #645   +/-   ##
===================================
  Coverage    60%    60%           
===================================
  Files       100    100           
  Lines      4702   4707    +5     
  Branches   1102   1104    +2     
===================================
+ Hits       2830   2836    +6     
  Misses     1386   1386           
+ Partials    486    485    -1     

Files with missing lines	Coverage Δ
Ical.Net/Evaluation/RecurrencePatternEvaluator.cs	73% <100%> (+<1%)	⬆️
...alization/DataTypes/RecurrencePatternSerializer.cs	70% <100%> (+<1%)	⬆️

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

[axunonb]

Great! Just a minor remark re Exception details

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[minichma]

@axunonb How should we deal with merging into v5? 3-way merge? Cherry-pick? Separate PR? I think I'd vote for the 3-way merge.

[axunonb]

Yes, the 3-way merge would be beneficial. But would updating main besides version/v5 aim for further v4 releases? Otherwise we could freeze v4.

[minichma]

Oh, I was unsure, about your plans regarding v4. Given the creation of a v5 branch I thought main would continue to exist for v4 for now, but I agree that concentrating on v5 would be beneficial. But, if we don't plan for further v4 releases anyways, why not continue developing v5 on main? And in case we think another v4 is needed, we would create a v4 branch (or do that right now). That's how I know it from other project like libical too.

[axunonb]

Really appreciate your input! Of course, that makes perfect sense.

[axunonb]

Created version/v4 and then merged version/v5 into main