Move EDTF validation to a constraint

[jordandukart]

Currently all the validation for the EDTF lives in the widget. While this works splendidly through the UI if another point of ingest is used (Workbench/REST/JSON:API etc) this validation will not get fired and can be inconsistent in the following scenario:

• A user ingests an object outside of the UI with an EDTF Date
• The EDTF is not valid with the configured validation upon edit
• The object is no longer able to be updated as it has invalid data.

It appears this could be moved over to use a constraint. Core Drupal also utilizes these to provide field level validation.

[mjordan]

Consensus at the 2021-06-30 tech call was that it would be good practice to use these contraints for any Islandora-specific custom field types. Also, some discussion that we should have a best practices guide for Islandora devs that would recommend using constraints.

[adam-vessey]

Braining a bit in this area recently, threw together Islandora/controlled_access_terms@2.x...adam-vessey:feature/edtf-constraints

However, struck with the issue: Moving to constraints would possibly include "promoting" few relevant bits of widget configuration to settings on the field (storage?), from where they are on the "widget", which potentially gets into writing update hooks to move 'em? Not the end of the world, but... given that they are then less-easily changed when there are values present on the storage side of things... unless... could possibly roll the config elsewhere? Or possibly roll some other mechanism to only allow "widening" conversions (so you can move to allow the use of sets/intervals, but not disable the capability to do so once enabled).

... or alternatively, ignore the set/interval settings, and just ensure that any content on the field looks like EDTF (to prevent arbitrary strings from migrations and whatnot).