Prevent that runtime checks are allowed in CLI context when they cannot be used

[felixarntz]

The Abstract_Check_Runner::get_checks_to_run() method has logic to determine whether to allow runtime checks, depending on the environment. Generally, runtime checks can only be used if the object-cache.php drop-in is already present (which will lead to early initialization) or if we know that the object-cache.php file can be placed.

This works as expected for the WP Admin flow, but not for WP-CLI: In WP-CLI, everything happens in a single request, so we can't just place the object-cache.php drop-in later. This means PCP will currently attempt to include runtime checks in WP-CLI context even when it should not.

This PR fixes this by moving the logic into its own method, which the CLI_Runner class then overrides to make the logic "stricter": It can only use runtime checks if the object-cache.php drop-in is already present, i.e. the runner was initialized early.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: felixarntz <flixos90@git.wordpress.org>
Co-authored-by: swissspidy <swissspidy@git.wordpress.org>
Co-authored-by: ernilambar <rabmalin@git.wordpress.org>
Co-authored-by: davidperezgar <davidperez@git.wordpress.org>
Co-authored-by: mukeshpanchal27 <mukesh27@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[ernilambar]

We could fix n.e.x.t since version in bulk in the time of new release. Lets not hold this now for that issue.