Add back support for parsing strings with "GMT" offset

[djc]

I'm trying to upgrade the cookie crate to time 0.2. As I understand it the relevant date format specification is https://tools.ietf.org/html/rfc2616#section-3.3.1. However, the current approach of not having %Z causes a bunch of pain for parsing these dates. Specifically, parse() for OffsetDateTime seems to return InsufficientInformation if I just try to parse with "GMT" in the format. So it seems I'd have to do a dance of (a) parsing a PrimitiveDateTime, (b) calling to_offset() on it, and (c) validating that it had the "GMT" or equivalent.

I think the approach of actually having %Z support only for GMT and UTC was probably a better trade-off, especially since that would allow both a numeric offset as well as some of these abbrevations. Otherwise, perhaps OffsetDateTime could maybe provide a parse_with_offset() (or just parse_utc()) method that allows a non-numeric offset literal in the format string while using the provided offset.

[jhpratt]

I'll actually be upgrading the cookie crate myself tomorrow — the time crate needs some prerequisites before moving forward with that. Sergio gave me the go-ahead earlier tonight. Just letting you know so there's no duplicated efforts 🙂

The approach I have taken in the conversion so far is to parse as a PrimitiveDateTime (using "GMT" explicitly), and then add the offset back in. Time v0.1 had its parsing handled identically to C, which is where the odd behavior came from. It did have surprising behavior in many situations, which is why I removed it. It'll be re-introduced when tzdb support is done (it's not yet started). That will go to a ZonedDateTime, as parsing offsets must be fixed (yes, UTC is, but many zones aren't).

[djc]

I actually already did most of the work, see rwf2/cookie-rs#134.

[jhpratt]

Thanks! I will go through and do a thorough review of changes. I was also going to upgrade it to 2018, but that can be a separate PR.

[jhpratt]

Closing in favor of #193, which will provide this and more.