Check that by day recurrences do not precede dtStart.

There is a bug in timesInInterval() when a recurrence rule recurs weekly by day (every week on Tuesday, Wednesday, Thursday for instance). If you call this routine with an interval beginning before the start day of the rule, then days matching the rule within the same week as the starting day of the rule but actually before it, will be returned. The MR contains a test demonstrating the issue.

This bug has been tracked by Chris Adams (see https://git.sailfishos.org/mer-core/kcalcore/merge_requests/9/diffs?commit_id=6fa6ee85172fb325cee38af2853159c719e3b524). I arrive to a slightly different solution than his.

The problem is in getNextValidDateInterval(), where for every other rules, there is a max() that ensure that a positive shift is applied to the starting date of the rule. In fact this max is also applied in our case, but the starting date to apply the shift is in that case, changed to be the start of the week. I guess there is reasons for this and we cannot change it there. Then, in timesInInterval(), the returned interval is used, and in the first iteration of the loop, a cut is applied to the list of possible dates. But the cut is done with the provided argument for the routine and not the starting date of the rule. That's what I'm changing here by changing st a bit before.

What do you think ?