Field UUID changes can badly corrupt field data

Problem/Motivation

Saving an existing field with a different UUID, including by attempting to import even an absolutely identical copy of the field that has a different UUID, puts a Drupal installation in an unrecoverable state.

1. Install 8.x standard.
2. Emulate a field machine name/UUID conflict by copying field.field.field_tags.yml from the active configuration directory to the staging directory.
3. In the staging directory, change the uuid of field.field.field_tags.yml slightly, e.g. just change the first character.
4. Visit admin/config/development/sync and click import.
5. Your site is broken. There's no escape. Any and every page load will show:
   
   Error message

Drupal\field\FieldException: Attempt to create an instance of unknown field old-config-uuid-here-nskjdfhisuhdfwf in Drupal\field\Plugin\Core\Entity\FieldInstance->__construct() (line 259 of /Applications/MAMP/htdocs/d8git/core/modules/field/lib/Drupal/field/Plugin/Core/Entity/FieldInstance.php).
The website has encountered an error. Please try again later.

Enjoy: https://www.dropbox.com/s/ogag30dfpqqkaqb/the_most_excellent_and_lamenta...

Note: This video also illustrates a related featurebug that is mostly just a minor WTF once this issue is resolved, which is that an exactly identical fresh installation has different UUIDs for all the same default configuration.

Proposed resolution

The field API should disallow changing the UUID of an existing field on save, since field instance data depends on this UUID.

Remaining tasks

• Consider moving the field UUID check out of FieldInstance::__construct() into FieldInstance::save(), so that a data integrity issue does not completely break Drupal.
• Provide test coverage ensuring the proper exceptions are thrown, both with an API save and functionally via a config import.