Fix the way we set date on WCS

[Cadair]

We got an in-person bug report from someone trying to reproject EUI/FSI to a SPICE map. SPICE headers (apparently all SolO data) have date-beg, date-avg and date-end in their header but to "support [...] older software" they also specify date-obs with the same value as date-beg.

All this is to setup the fact that we only set dateobs on the WCS we build in map from our date property which (in order) pulls from these sources:

1. The DATE-OBS FITS keyword
2. .date_average
3. .date_start
4. .date_end
5. The current time

This means that the WCS object we build for SPICE (which is a GenericMap) uses DATE-OBS which isn't the time corresponding to the observer location, and can in fact be out by hours.

This fix priorities setting wcs.dateavg which is more correct and should fix the specific SPICE issue.

[ayshih]

For EUIMap, we override the .date property in the subclass such that it prioritizes DATE-AVG (#5462 and #6549), so the reason that we can't do that for the SPICE map is because we don't have a subclass for it?

I'm uneasy that this PR changes how GenericMap works for such a header, and it allows for a potential complete disconnect between what the .date property returns (DATE-OBS) and the three dates inserted into the WCS (DATE-AVG, DATE-BEG, and DATE-END). In a general case, DATE-OBS is not necessarily equal to DATE-BEG.

Also, this PR doesn't fix the SPICE problem entirely. The motivation for overriding .date for EUIMap is because the observer-location metadata in the header is specified for the DATE-AVG time rather than the DATE-OBS time (see #5450). Since this PR does not change the use of the .date property by the .observer_coordinate property, the observer coordinate is presumably inaccurate.