[PP-1] Document how to ship the dependency container in code

Problem/Motivation

Document is in the title but we might end up needing code changes to actually enable it too.

#3583505: Use Symfony PhpDumper instead of a serialized array container structure allows the container to be stored as a php class. There are concerns on that issue that the mtime check from MtimeProtectedFileStorage as well as the mtime check from opcache itself might cause problems over NFS.

Symfony encourages sites to ship a single container file with the deployed code base, but even after the above issue it's a bit more complicated for us, however it should be possible.

Drupal's container is based not only on the code base, but also the modules enabled and in some cases other configuration (like monolingual vs multilingual). The container class used depends on the modules enabled etc., and the exact contents of that class depend on the code base. Either one or the other can change during a deployment.

During a deployment, we first need to run updates and import config - both of these might install or uninstall modules or themes, potentially resulting in more than one container rebuild.

This means that rather than a single container in the code base, we'd actually need multiple:

1. Code is deployed, if the contents of the container change based on code changes, then the container can be immediately updated (this is already somewhat enforced be $settings['deployment_identifier'].

2. Updates and config sync run, different container classes with different hashes may be compiled (not always), if this happens more than once they will be 'interim' containers.

3. After the deployment, the new container class with the new hash is used consistently.

Steps to reproduce

Proposed resolution

To enable this, sites would need to include the old container, probably any interim containers, and the new container.

The production site will not have the new hashes in the cache table, so these will be generated as they otherwise would, but then instead of writing the PHP file, it would already be found on disk.

The existing code already avoids trying to write to a file if it's found, so the main difference would be using a phpstorage that doesn't delete - but it would need to write on development environments.

Remaining tasks

We need to try configuring the container storage with standard phpstorage, pointing this to a location outside the webroot, committing the contents of the directory to git with different combinations of modules, and then truncating the container cache, and then installing/uninstalling modules - it should transparently use the existing containers on disk without trying to write or delete anything.

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet