date time formatting, take 3.

[tsteven4]

This is a complete working version that builds on drafts #1205, #1208. It eliminates the use of strptime/strftime.

There are two parts to this problem:

1. The front end. Translating from a (yet to be) published gpsbabel defined date time string to that used by internal processing (the back end). The front end implemented in convert_human_datetime_format, in util.cc
2. The back end. converting the string input to date time information, or converting the date time information to a string. In this implementation the back end is QDateTime::fromString or QDateTime::toString.

For the front end we accept the following format specifiers: yy, yyyy, M, MM, d, dd, h, hh, H, HH, m, mm, s, ss, xx, XX. These are interpreted as QDate and QTime would except xx=>ap and XX=>AP. punctuation, with the exception of a single quote, and spaces may be used as well. A repeated single quote is interpreted as a single quote. Other characters must be quoted with single quotes. A repeated single quote can also be used within single quotes to represent a single quote.

The users are garmin_txt (from and to string), the track filter title option (to string), and xcsv read/write (from and to string). The title option requires arbitrary text, hence all the quote handling.

The back end has some quirks.

1. Unlike strptime, QDateTime::fromString requires the entire format string to match.
2. It also fills in default values for any part of date or time that aren't in the format string. This required rewriting a xcsv test so we could convert entire input strings. It also requires the front end to communicate which fields are actually being converted so we can intercept the defaulted values (for xcsv).
3. Another quirk is that we use QDateTime::fromString to convert a date, or a time, or a date and a time, but without any restriction that they are a real datetime in some timezone. To be safe I force the conversion to UTC so fromString won't return an invalid datetime, e.g. in hour that doesn't exist in the transition to DST. Subsequent to conversion to QDateTime the date and time pieces are joined in xcsv usage based on the XT_* fields used.
4. Another Qt quirk is that a double single quote is used as an escaped single quote in toString, either inside or outside of a quoted section. But fromString uses a backslash quote to escape a quote in a quoted section, and doesn't seem to allow an escaped quote in an unquoted section. I haven't found any documentation for fromString's handling of backslash quote other than the source code.
5. trackfilter used to detect a % in the format string implying date/time was converted. It creates titles differently depending on this. In this implementation the title option is used for static title information, and a new dtitle option is used for titles that depend on date time information.

Alternatives: For the front end we could define our format to use strptime/strftime type conversions specifiers, i.e. where each starts with a %. For the back end we might be able to use std::get_time, std::put_time instead of QDateTime::fromString,, toString. The backend choice of put_time/get_time might positively impact some of the quirks. The frontend choice of % specifiers might be easier to parse, but seems less "human". However, the present implementation does seem to adequately covert the requirements.

None of these handle fractional seconds.

TODO:

1. have xcsv convert the format strings once with the style, instead of at every usage.
2. remove strptime from the build.