Implement issue# 12886: function for parsing RFC822/5322 date-time format.

The RFC 822 / 5322 date-time format should be taken out and shot, but
unfortunately, it _is_ used in e-mail, HTTP, RTSP, etc. Most code which
deals with it is probably going to need to handle the rest of whatever
spec it's interacting with rather than just the date-time format, but
there are cases where this would be useful on its own (e.g. Martin
apparently needs something like this in the dmd installer), so I'm
adding a function to parse this format and return a SysTime to
std.datetime.

However, that's all I'm adding. I find it very hard to believe that
anyone who needs to produce this particular format doesn't need a lot of
other functionality specific to whatever spec they're dealing with, and
the function for generating the date-time format presumably will be
included with that (and I definitely don't want to encourage this
format's use anyway, since it's a horrible format). So, I'm just adding
a function for parsing the format, not generating it.

parseRFC822DateTime _should_ fully and correctly implement the format as
outlined in RFC 5322 (including the obsolete syntax from RFC 822 that no
one is supposed to be generating anymore and the comment folding
whitespace nonsense that should never have been legal anywhere but at
the end). And the tests are quite thorough, so it's unlikely that I
missed anything, but you never know.
Well, I would expect `goto '\r'` to jump straight to `case '\r'`, which _would_ avoid comparing against `' '` and `'\t'` again. I specifically wrote `_stripCFWS` so that it would compare each character only once and not compare for empty more than once per character (which _should_ make it faster), but I haven't extensively benchmarked or profiled it yet either.

However, regardless of what's faster, I'll make your suggested changes, since it's less code, and this particular function is only used by `parseRFC822DateTime`, and (comment) folding whitespace should be fairly rare in there (much as this function is required for correctness), so the speed of this function shouldn't have a large impact here. Where it really matters is in implementing RFC 5322 in general, but that's not going to go in Phobos (though it will affect the library that I'm working on, and I'll have to make sure that I benchmark and profile that more thoroughly to make sure that the extra code is worth it and remove it if it isn't).