Support RFC 9651

[apasel422]

RFC 9651 adds Date and Display String bare item types.

The actual parsing and serialization code for these isn't complicated, but design-wise we could integrate them in a few different ways:

1. For ergonomics and backwards compatibility, we could have separate enums like rfc8941::BareItem and rfc9651::BareItem, the former of which would be identical to BareItem as it is today, the latter of which would have two additional variants for the new types.

2. Alternatively, we could push for RFC 9651 as this crate's default, and therefore add Date and DisplayString variants directly to the existing BareItem type, but still allow users to decide which variant they want to parse using an option on Parser. The downside to this is that code that matches on the enum will have to handle the BareItem::{Date, DisplayString} variants even though they are guaranteed never to be produced when parsed under the RFC 8941 configuration.

Thoughts?

[valenting]

I'm in favor of no 2. I think RFC 9651 should be the default. Since some headers may have been defined to reference RFC 8941 where date and displayString should never parse, I think having a Parser option to parse using 8941 makes sense. We haven't yet released a 1.0 crate, so I don't think it's unreasonable to change the BareItem enum. We might even consider making the enum non_exhaustive if there is reason to think other types will get added in the future, but I don't believe that's a near-term problem.

[apasel422]

For Option 2 we will also have make the serializer configurable, and return an error or panic when a date or display string is serialized using RFC 8941.