The Views integration Datetime Range fields should extend the views integration for regular Datetime fields

Follow-up to #2161337: Add a Date Range field type with support for end date

Problem/Motivation

datetime_field_views_data() performs some nice improvements for the Views integration for datetime fields, but has not yet been updated to cover daterange fields, so daterange fields only receive the integration provided by the views_field_default_views_data() fallback. This means that for example, the year-only, month-only, etc. formats aren't available as arguments for daterange fields like they are for datetime fields.

Proposed resolution

The proposed resolution is to allow datetime views plugin to be used for datetime_range fields too. Together with this we have to make sure: extending/reusing the current datetime implementation becomes an easy task for developers, any existing views making use of datetime_range fields is correctly updated, default views shipped with contrib modules using old plugins are automatically migrated on save, etc.
In order to achieve that the solution should include the following tasks:

• Extending the datetime fields Views integration in order to allow any datetime-based fields to make use of it. #4
• Letting daterange fields use the same Views integration capabilities that datetime fields have, using the work from previous point. #4
• Providing an upgrade path for views having old datetime_range fields string/standard views plugins to new plugins types. #24 ~ #139
• Updating contrib modules provided views having old datetime_range fields string/standard to new plugins types. #133 ~ #142

Remaining tasks

• map current 'string' view plugin values/operators to new 'datetime' plugin on the update path using regular_expression operator
• take care of contrib views too. Move all the existing update logic to hook_view_presave and just do $view->save() in the update hook when appropriate as described in #133
• update path test for #127 and #129 changes
• Convert Webtestbase based testing to Browsertestbase
• Deciding if we need a stronger message alerting the user to manually review the views being converted (and/or may be a Change record?). Change Record added.
• Update the issue summary:
  • User interface changes: the IS should mention this issue is neither adding nor removing UI elements, instead we are moving from string/standard views plugins UI to datetime ones. A screenshot with "before - after" should help.
  • API changes: "Extending the datetime fields Views integration in order to allow any datetime-based fields to make use of it" solution task introduce a new API helper for datetime-based fields who want to integrate datetime views plugins easily.
  • Data model: we are not changing any data model. However existing and contrib modules shipped views may be altered. Developers and site builders should be aware of that.

• UI/API/Data Model changes above need a place in the CR - together with a good clean up - as flagged by #192.7
• Upgrade test path is still using old simpletest. We should move it to use Drupal\FunctionalTests\Update\UpdatePathTestBase

User interface changes

This issue doesn't introduce new UI elements, but it converts Views filter and sort plugins from string/standard formats to datetime based ones. The change is automatic, site-builders and developers don't need to do any action.
See the example below of how the UI will change for a Views filter plugin against a datetime_range field:
Before:

After:

API changes

datetime_type_field_views_data_helper - new API helper to integrate datetime views plugins easily for any datetime-based fields. Modules defying datetime-based fields can now benefit of datetime Views plugins easily.

Example usage in core/modules/datetime_range/datetime_range.views.inc:

/**
 * Implements hook_field_views_data().
 */
function datetime_range_field_views_data(FieldStorageConfigInterface $field_storage) {
  \Drupal::moduleHandler()->loadInclude('datetime', 'inc', 'datetime.views');

  // Get datetime field data for value and end_value.
  $data = datetime_type_field_views_data_helper($field_storage, [], 'value');
  $data = datetime_type_field_views_data_helper($field_storage, $data, 'end_value');

  return $data;
}

Data model changes

There are no Data model changes. However existing and contrib modules' shipped Views - using datetime_range fields/plugins - may be altered. See update message about the ids of changed views like (view id is datetime_test):

The update will map existing datetime_range views string plugins operators/values according with this list:

• = maps to =, value is unchanged
• != maps to !=, value is unchanged
• not maps to !=, value is unchanged
• starts maps to regular_expression, value is prefixed with '^'
• ends maps to regular_expression, value is suffixed with '$'
• any other operator (contains, word, allwords, not_starts, not_ends, shorterthan, longerthan, regular_expression) maps to regular_expression, value is unchanged if not empty otherwise *. is used

Example, filter Starts with with 'value' will be converted into Regualr expression with '^value';