Escape one character trimmed date formats

[SimonCropp]

DateMatchers.BuildForFormats builds a second scrubber for the trimmed format when a format ends in an upper case fraction, since those render as empty when the fraction is zero. TryGetFormatWithUpperMillisecondsTrimmed handed back the trimmed string raw, and a one character format string is read as a standard format specifier rather than the custom one it was written as:

• ScrubInlineDateTimes("s.F") trimmed to "s", which expands to the culture's sortable pattern — so the second scrubber scrubbed every full sortable date-time in the output.
• ScrubInlineDateTimes("H.F") trimmed to "H", which is not a standard specifier at all — Invalid format: H at registration, after the format had already passed the up-front validation.

Now % escapes the trimmed format when one character is left, which is what forces it to be read as a custom specifier, and no second scrubber is built when trimming leaves nothing (".F").

Tests in the new TrimmedFractionTests cover all three cases; all three fail on main. ApplyScrubbersTests (114), Verify.Tests (1299) and StaticSettingsTests pass.

Unrelated observation while in here: the trim only recognises .F through .FFFF, so .FFFFF through .FFFFFFF never get a trimmed scrubber. Left alone since TryParseExact treats the fraction (and its period) as optional anyway, which makes the second scrubber look redundant rather than missing — worth a separate look at whether it earns its keep at all.