Meta: Ensure all possible things are reloaded after an update

Problem/Motivation

1. After an update things will have changed, new things will be added, and existing things will be removed in core and modules(when we support them)
   Among those things are
   • global functions in .module files and .inc files
   • routes
   • any classes
   • services definitions
   • plugins
   • etc
2. Certain of those things, especially if they were loaded before the update occurred, will be cached in some way.
3. Any code that has changed may be immediately accessed by subscribers of PostApply, in later parts of the Drupal request, or in the next http request
4. if we don't clear or rebuild caches properly code that runs after the update may still be accessing the cached version of code from before the update

Proposed resolution

Solving all of this will likely take a few issues.
#3269097: Add test coverage to determine if global functions are reloaded when updates are applied starts with testing if global functions in .module files are reloaded(they are not). That also creates an Update Checker module that will check what has been reload.

After #3269097, is committed we will be able check if other things are reloaded by:

1. Added a new thing item and/or change an existing item in updated_module
2. Add the check in update_checker(currently \Drupal\updater_checker\UpdateChecker::runChecks)
3. Added a new expected result in <code>\Drupal\Tests\package_manager\Build\PackageUpdateTest::testPackageUpdate

Remaining tasks

Create individual issues for

1. #3268363: Load new services after staged changes are applied
2. #3269097: Add test coverage to determine if global functions are reloaded when updates are applied - Update checker module for other issue in this issue
3. Plugins
4. Routes
5. .inc file loaded by \Drupal\Core\Extension\ModuleHandler::loadInclude(). Test a case where the file is loaded in Pre Apply and one that isn't
6. New permission, removed permission
7. Entity types

Other follow-ups

1. Determine if there are any types of things, like classes or global, functions that can't be reloaded immediately after an update and where a PostApply subscriber will always be loading the pre-update version. If there are any of these things document them and suggest ways around this.
2. Determine if we should ensure our cron implementation runs last to ensure other cron implementations are not accessing cached things