Old post_update functions that ->save() config entities without calling ->trustData() first mask errors in other post_update functions

Problem/Motivation

• In #2949351: Add a helper class to make updating configuration simple → , we added ConfigEntityUpdater as the new standard way of updating config entities from post_update functions.
• That class calls ->trustData() before calling ->save().
• That's good, because it requires the post_update function itself to set schema-valid values, otherwise assertConfigSchema() will flag a schema violation and test failure during upgrade path tests.
• However, we have a couple dozen existing post_update function from Drupal minor versions that were released prior to #2949351: Add a helper class to make updating configuration simple → being added, that ->save() config entities without calling ->trustData() first.
• If these run after a newer post_update function (for example, if running/testing a database update directly from 8.4 to 8.6 without updating to 8.5 first), then if the newer post_update function sets a schema-invalid value, the older post_update function will clean it up, and the upgrade path test will pass. However, that masks the fact that an update from 8.5 to 8.6 has an error.
• We ran into a concrete case of this in #2988435: block_content_post_update_add_views_reusable_filter uses an string instead of int for "group" → .

Proposed resolution

• Option 1: Change the already released post_update functions to call ->trustData() before calling ->save()?
• Option 2: Change the already released post_update functions to use ConfigEntityUpdater, which is effectively the same as option 1, but with additional refactoring?
• Option 3: Don't change already released post_update functions, and instead begin all new upgrade path tests from an 8.5 database?

Remaining tasks

User interface changes

API changes

Data model changes