Improve the UX of update.php's handling of entity type updates

Follow-up from #2333113: Add an EntityDefinitionUpdateManager so that entity handlers can respond (e.g., by updating db schema) to code updates in a controlled way (e.g., from update.php). In that issue we introduced a new kind of update. In addition to the familiar updates that are defined by hook_update_N() functions, we added EntityDefinitionUpdateManager, which checks if the current codebase is defining and using modified entity type and field storage definitions that the entity handlers need to be notified of. This is done as part of update.php, because an example kind of handler is SqlContentEntityStorageSchema, which needs to update the database schema to work for the new definitions. In Drupal 7, these kinds of entity table changes were done as update functions in the entity type's module: for example, node_update_7005(), but in Drupal 8, those tables are under the control of swappable handlers (e.g., one could use a NoSQL backend), and hooks like hook_entity_type_alter() and hook_entity_base_field_info_alter() make it so that there's no one clear module that should define the hook_update_N() entry point. So, instead, those updates are summarized and invoked by EntityDefinitionUpdateManager rather than as hook_update_N() functions.

Several issues emerge from this, however, that could use some UX improvement:

1. Does it make sense to list these updates on the same step of update.php, as currently, or should we switch to a dedicated step in the UX flow? For example, see screenshots in #1498720-145: [meta] Make the entity storage system handle changes in the entity and field schema definitions that were proposed, but we backed away from in #2333113: Add an EntityDefinitionUpdateManager so that entity handlers can respond (e.g., by updating db schema) to code updates in a controlled way (e.g., from update.php) due to wanting more UX discussion about that.
2. What should the labels say? They currently say things like "Create the Foo field", "Update the Foo field", "Delete the Foo field", or "Update the Bar entity type" (see screenshot in #2333113-65: Add an EntityDefinitionUpdateManager so that entity handlers can respond (e.g., by updating db schema) to code updates in a controlled way (e.g., from update.php)). However, that's not 100% accurate, because in some sense those creations/updates/deletions already happened regardless of running update.php: the codebase immediately uses the new definitions as soon as the code is deployed. What update.php is doing is just notifying the handlers of those creations/updates/deletions, so that they can react, by e.g., adjusting the database schema if necessary. Are there generic labels that can explain this, or should we add make it the responsibility of each handler to return specific text about what it will do?
3. If there's existing data in the entity tables, and the schema change requires dropping and recreating the table, or moving the data to a different table, the update currently fails with a generic "The SQL storage cannot change the schema for an existing entity type with data." error message. How can we improve the UX of that? For example, should we mention that in the overview step and disable the "Apply pending updates" button, rather than only mentioning it after the user clicked that button?