Stale generated storage classes are not invalidated across web heads

Problem/Motivation

Followup for #3452414: Refactor storage class generation.

Deleting the generated files is not enough on its own: within the request that deletes them PHP has already loaded the old class, so include_once() will not redefine it. That request is usually drush updb, where post_update hooks run after every hook_update_N, so all of those have already run against the stale class.

With more than one web head it is worse. PhpStorageFactory defaults to the shared public files directory, so deleteAll() does reach every head today. As soon as $settings['php_storage'] points at local disk it clears only the head that runs the update, and the others keep loading the old file under its unchanged name.

Proposed resolution

Put a hash of the template in the generated class name, so the name changes when the generated code does and never otherwise. Every head derives the same name and stale files are never referenced again, so nothing has to be signalled or remembered. This is what core will soon be doing as well in #3583505: Use Symfony PhpDumper instead of a serialized array container structure.

Compute it in TrashServiceProvider::register() as a container parameter, so it is compiled into the container and costs nothing per request. Only the template is hashed: the trait, the interface and the parent class are resolved by the autoloader when the class is linked, so their code is never stored in the generated file.