Entity Definition Update Manager should raise exception on no-op/unsupported changes

In #2542748: Automatic entity updates can fail when there is existing content, leaving the site's schema in an unpredictable state, core stopped supporting automated/auto-magical updating of entity field definitions post entity install. The CR for this change states:

...that magic was removed and now changes to the entity schema are to be included as regular update functions.

Good stuff. As a result, the Entity Definition Update Manager provides a number of helper functions for updating these definitions "correctly."

Custom module maintainers may, however, attempt updates that will result in either a no-op or a mismatched field definition vs. an installed schema. Consider the example of a string field; a developer may believe it possible to update the schema thusly:

$entity_definition_update_manager = \Drupal::entityDefinitionUpdateManager();
/** @var \Drupal\Core\Field\BaseFieldDefinition $field_storage_definition */
$field_storage_definition = $entity_definition_update_manager->getFieldStorageDefinition('field_name', 'entity_name');
$field_storage_definition->setSetting('max_length', 51);
$entity_definition_update_manager->updateFieldStorageDefinition($field_storage_definition);

This will update the definition, partly, however the schema of the backing field will not be changed and the entity will continue to show as needing an update in the Status Report UI. Since the UI message does not provide context beyond "needs update," this can result in frustration and confusion.

Since the entity definition update manager is a developer-facing API with no UI attached, it would be appropriate to throw some type of runtime exception when we can detect such changes won't "take."