Documentation of PCP check process flows in all scenarios

The process flows in the different scenarios in which PCP can be used are quite complex to understand, most notably when runtime checks are involved. The complexities for runtime checks mostly stem from the fact that part of the functionality needs to be initialized very early, before plugins are loaded, which is achieved by temporarily placing an object-cache.php drop-in (if possible).

This issue is about documenting those flows to help contributors better understand these flows and potentially uncover current bugs.

Since I was heavily involved in the architecture of the plugin and making runtime checks possible in safe way, I went over the code in depth again (which was also very helpful to refresh my memory!) and documented the current flows individually. For now, I put it all in this public document, for easy discussion via contextual comments: https://docs.google.com/document/d/1wDGZBwWB2WAxfbHE3lygIzQFK8IssCa5apOyaBolukQ/edit
Please request comment access if you'd like to leave comments.

Note that I did encounter some problems while documenting the flows, particularly about supporting checks added via other plugins ("addon checks"). I added comments on the doc for all of those problems. I would like to use this documentation issue also as an opportunity to discuss solutions to those problems.

For reference, listing the problems found here (roughly ordered by severity):

• Force_Single_Plugin_Preparation prevents plugins other than PCP and the checked plugin from being active when any runtime checks are included, preventing addon checks to work in that context. See doc comment. and #608 for a PR that fixes this.
• When running runtime checks, the database table prefix is only modified when actually running the checks, but active plugins are still filtered. This can lead to unexpected modification of the actual site database. A solution would be to modify the database table prefix more or less throughout the entire request. See doc comment. and #768 for a PR that fixes this.
• In WP-CLI context, runtime checks may be run when they shouldn't, which could lead to unexpected results with other plugins active. See #598 for a PR that fixes this.
• Abstract_Check_Runner::get_checks_to_run() is called before plugins are loaded when initialized early, just to determine whether runtime checks are included or not. This means addon checks will not be considered, even though they may include the only runtime check requested. See doc comment. and #612 for a PR that fixes this.

But first and foremost: Please review the doc if you're interested, and leave questions wherever something may still be unclear.