Add DateOptionGroup

[bdarcus]

My current plan, carried over from discussions for the v1.1 branch of CSL, standardizes on an EDTF string for input, and I'm hoping to convert to an EDTF Date object when deserializing in #46 (though this may be too ambitious, given there are many different types of objects in EDTF).

But formatting?

I'd prefer to avoid reintroducing the 1.0 date/date-part structures if possible, since it's another piece of template complexity.

The JS toLocaleDateString method looks like a pretty awesome approach.

> const dateConfig = { weekday: "long", year: "numeric", month: "short", day: "numeric"}
> d1.toLocaleDateString('en-us', dateConfig)
'Thursday, Apr 27, 2023'
> d1.toLocaleDateString('es', dateConfig)
'jueves, 27 de abr de 2023'
> d1.toLocaleDateString('de', dateConfig)
'Donnerstag, 27. Apr. 2023'
> d1.toLocaleDateString('ja', dateConfig)
'2023年4月27日木曜日'

const d1 = edtf("2016-10");

const d_month_day = { month: "short", day: "numeric" };
const d_full = { year: "numeric", month: "long", day: "numeric" };

console.log(d1.toLocaleDateString("en-us", d_month_day));
console.log(d1.toLocaleDateString("es", d_full));
console.log(d1.year);

Of note:

1. it has some conceptual similarity to how we localize terms in 1.0.
2. it's configured in an object (order doesn't matter there)
3. details like order and punctuation are localized (though I don't know how or where)

See also the newer Intl.DateTimeFormat, which is similar:

> (new Intl.DateTimeFormat('en-GB', { dateStyle: 'full', timeStyle: 'long', timeZone: 'Australia/Sydney' }).format(d1));
'Thursday, 27 April 2023 at 22:04:49 GMT+10'

But I think we may be able to get away with adding Dates as an OptionGroup?

I think I'll try to go with this first, as it keeps things simple, but promises to be international-friendly.

If it didn't work, would need ability to localize within styles, with approaches like this:

date.format(now, 'ddd, MMM DD YYYY');