Rewrite QDateTimeParser

The present QDateTimeParser code reads its string sequentially, using information from earlier in the string, along with a "guessed" date, to help it make sense of each field as it comes to it in succession. This is a pretty poor way to work, when information later in the string may over-ride the guesses being used to make sense of what appeared earlier; as a result, it has all sorts of funky heuristics about cancelling and over-riding earlier guesses and heuristics.

The format string we're using to guide parsing could be used to split up the string at the beginning, before we look at the content of the resulting fragments any more closely than a basic lexical "is it a digit" or "is it the separator we expect here" level. We could then extract the time-zone or offset (when given) first, no matter where in the string it appears (very often at the end, exactly the worst place for it with the present sequential approach), then extract the year (again, often late in the string), then month (using the year, for those calendars for which it's relevant, to guide us), then the day of month (now that we know how many days there are in the month) and so on. It'll surely be more complicated than that, but the general approach of splitting it up first and then making sense of the pieces in an order that suits us would surely be more robust (and better able to handle complications such as I expect we'll hit with some of the more interesting calendars).

It is even respectably likely that such an approach would prove faster than the present approach, as it would need to do less back-tracking to correct guesses made earlier. It would also avoid instantiating any QDateTime instances until it had all the information it needs to do so, instead of instantiating one (or more) per field of the date-time text, as it is parsed. When it does instantiate a QDateTime, furthermore, it won't attempt to resolve any zone-specific strangeness (DST, &c.) unless it actually needs to (instead of doing so over and over again until it discovers it was all unnecessary, as in the present implementation), and even then it will only do so once, for the date-time the string actually does represent (rather than for a succession of different date-times, each taking into account one more field than the previous).