Convert field_storage_config and field_config's form validation logic to validation constraints

Problem/Motivation

As long as field_storage_config and field_config are not validatable (see #2164373-28: [META] Untie config validation from form validation — enables validatable Recipes, decoupled admin UIs …, it will be difficult to build a "Field UI 2.0" with confidence, and we definitely won't be able to create such a thing as a decoupled JS application.

This would also allow us to remove the following in \Drupal\Tests\field\Kernel\FieldStorageCrudTest:

  // TODO : test creation with
  // - a full fledged $field structure, check that all the values are there
  // - a minimal $field structure, check all default values are set
  // defer actual $field comparison to a helper function, used for the two cases above

Proposed resolution

Remove form-coupled validation logic from:

field_storage_config

• \Drupal\field_ui\Form\FieldStorageAddForm::validateForm()
• \Drupal\field_ui\Form\FieldStorageAddForm::validateAddNew()
• \Drupal\field_ui\Form\FieldStorageAddForm::validateAddExisting()
• \Drupal\field_ui\Form\FieldStorageAddForm::fieldNameExists()
• \Drupal\field_ui\Form\FieldStorageConfigEditForm::validateCardinality()

field_config

• \Drupal\field\Entity\FieldConfig::postCreate()
• \Drupal\field\Entity\FieldConfig::preSave()
• \Drupal\field_ui\Form\FieldConfigEditForm::validateForm()

… and keep the existing test coverage the same, at most expand it.

Note that additional validation constraints will be necessary beyond what already exists, because a form-based UI only allows certain inputs, not arbitrary inputs, which are possible via an API.

Remaining tasks

TBD

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

TBD