Drupal 7 date fields with "todate" ("End date" in UI) setting enabled to collect a range lose their end date upon migration: data loss!

Problem/Motivation

The Drupal 7 date module allowed the site builder to configure whether to collect an end date or not:

(This is called 'todate' in the code.)

For example, on my personal site, I have a projectNodeType which has a "time range"date. Example: https://wimleers.com/work/project/ledgrid.

Upon migration, the start value (value) is migrated, but the end value (value2) is dropped

D7

D8 HEAD

That's because this is being migrated to a @FieldType=datetime field in D8 instead of a @FieldType=daterange field in D8!

⚠️🔥 This is data loss! 🔥 ⚠️

Proposed resolution

Make \Drupal\datetime\Plugin\migrate\field\DateField detect the todate setting and:

1. expand the process chain to also transform data for @FieldType=daterangeend_value property, instead of only the value property
2. dynamically override the statically computed destination field type: return daterange instead of datetime when appropriate
3. most simple, but perhaps most controversial: change the destination_module key in the @MigrateField annotation to datetime_range instead of datetime. The migration system seems to not have been designed for dynamic conditional edge cases like this one, and the harm of requiring that module to be installed even if unused is minimal; and certainly does not outweigh the data loss that is currently happening.

Remaining tasks

TBD

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

TBD