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.
It's illegal. No newlines or carriage returns are ever supposed to be by themselves, and only `"\r\n"` is supposed to be legal to indicate the EOL. However, HTTP unfortunately broadens that to allow `"\n"` in order to support non-compliant implementations. The whole "folding whitespace" nonsense comes into play when they want a way to continue a line without making it too long so, they have `"\r\n "` or `"\r\n\t"` which are supposed to be equivalent to `" "` and `"\t"` respectively when decoding the message. HTTP then broadens that to `"\n "` and `"\n\t"`. Regardless, `'\r'` not followed by a `'\n'` is still illegal, so the way that I chose to handle that was to just treat it like the end of the range, which will then result in the caller failing to parse whatever it's parsing (which in this case is the date-time format, though I have a library that I'm working on which fully implements RFC 5322, which uses this function for a lot more).