Fixed normalization of "Date" and "Date range" fields configured to store "Date and time" or "Date only"

1. @FieldType=datetime and @FieldType=daterange fields configured to store date + time:
   

   Before

   '2017-03-01T20:02:00'
   

   Note: timezone information is absent!

   After

   '2017-03-01T20:02:00+11:00'
   

   Note: the site's timezone is present! This is now a valid RFC3339

2. @FieldType=datetime and @FieldType=daterange fields configured to store date only:
   

   Before

   '2017-03-01T20:02:00'
   

   Note: time information is present despite this being a date-only field!

   After

   '2017-03-01'
   

   RFC3339 only covers combined date and time representations. For date-only representations, we need to use ISO 8601. There isn't a particular name for this date-only format, so we have to hardcode the format. See https://en.wikipedia.org/wiki/ISO_8601#Calendar_dates.
   

Also see https://www.drupal.org/node/2859657. Note that #2926508: Add DateTimeNormalizer+TimestampNormalizer, deprecate TimestampItemNormalizer: @DataType-level normalizers are reusable by JSON:API changed the implementation details of https://www.drupal.org/node/2859657 / https://www.drupal.org/node/2768651, so that those normalizers no longer run at the field type level, but at the data type level. It is in fact that change that helped us fix the datetime + daterange fields in one go!

Now @FieldType=timestamp, @FieldType=datetime and @FieldType=daterange are all handled consistently. None of them use field-level normalization. All of them use @DataType-level normalization.
Those 3 field types use only 2 data types: @DataType=timestamp and @DataType=datetime_iso8601. Both of those data types (and hence all field types that use them) automatically benefit from consistent behavior. They're now all normalized to RFC3339 datetime representations. @FieldType=timestamp already was doing this, and the absence of changed tests for the @FieldType=timestamp case guarantees that nothing has changed.