Ensure we can provide an upgrade path between 8.x versions

Note that the various D8 config update modules insist on having a UI that pushes the responsibility/complexity of reviewing updates to the end-user.
The average end-user will run away screaming.

Instead, we as module maintainers need to make the decision ourselves, in our update hooks. Having an API to use in update hooks currently feels better than trying to automate it, but let's see how to code turns out.

We'll also want to document common cases such as:
- Updated view
- Added configurable field
etc

mglaman has made good progress on the config update helper class.

https://github.com/drupalcommerce/commerce/pull/347

After many iterations we've created the ConfigUpdater service that covers the needed functionality:
https://github.com/drupalcommerce/commerce/commit/af4e4bb3507cc1119e92ea...

Verbose usage example:

/**
 * Placed in commerce.post_update.php
 */
function commerce_post_update_example() {
  $config_updater = \Drupal::service('commerce.config_updater');

  // The 'views.view.commerce_products' view was updated in the module, and
  // should be updated on the site unless the user has already modified it.
  $first_result = $config_updater->revert(['views.view.commerce_products']);

  // The 'commerce_product.commerce_product_type.default' product type was
  // updated in the module and should be updated on the site regardless
  // of whether the user has already modified it
  $second_result = $config_updater->revert(['commerce_product.commerce_product_type.default'], FALSE);

  // The 'system.action.commerce_publish_product' action was removed from the
  // module, and should be removed from the site.
  $third_result = $config_updater->delete(['system.action.commerce_publish_product']);

  // Let's pretend this is a more generic replacement for the old publish action.
  $fourth_result = $config_updater->import(['system.action.commerce_superpublish_product']);

  $message = '';
  // Each updater call allows multiple config names, and returns a result
  // with success and failure messages. Merge them, and show them to the user.
  $success_results = array_merge(
    $first_result->getSucceeded(),
    $second_result->getSucceeded(),
    $third_result->getSucceeded(),
    $fourth_result->getSucceeded()
  );
  $failure_results = array_merge(
    $first_result->getFailed(),
    $second_result->getFailed(),
    $third_result->getFailed(),
    $fourth_result->getFailed()
  );

  if ($success_results) {
    $message = t('Succeeded:');
    $message .= '<ul>';
    foreach ($success_results as $success_message) {
      $message .= '<li>' . $success_message . '</li>';
    }
    $message .= '</ul>';
  }
  if ($failure_results) {
    $message .= t('Failed:');
    $message .= '<ul>';
    foreach ($failure_results as $failure_message) {
      $message .= '<li>' . $failure_message . '</li>';
    }
    $message .= '</ul>';
  }

  return $message;
}

Matt will do a blog post soon.

@agoradesign
I wouldn't want to duplicate the config_update module (which has already settled on its own API).
In my opinion this code needs to live in core.

mglaman is adding the isModified() helper to #2656370: Create a method to discover if configuration matches the shipped configuration and I've opened #2684081: Modules need a way to keep their configuration up to date for the entire thing.