Add `canvas:doctor` Drupal CLI command to check health of Canvas' data: validate every Canvas (content|config) entity + translation, validate every non-Canvas content entity component tree field revision+translation, and more
Title says it all.
Context: Acquia Source has adopted Canvas long before it had a stable data model, and hence long before Canvas provided update paths. This has proven to cause seemingly random bugs during deployment, but time and time again the root cause has been data created _before_ Canvas provided update paths. This has been a time-consuming and costly affair (e.g. #3578865, #3579086).
Canvas has invested _heavily_ into thorough validation to spot data integrity problems, to be able to guarantee that "if it passes validation, it will work [render + be editable with good UX]".
## Proposal
⇒ We should make that validation infrastructure available to monitoring/auditing/site health checks too.
Drupal 11.4 will ship the `dr` CLI: https://www.drupal.org/node/3584928. Let's make Canvas leverage _that_.
(As soon as Drupal 11.4 is out, core drops support for 11.2. That means Canvas will be able to require 11.3, not 11.4. But it's reasonable to provide this command only for 11.4, because it's forward-looking and maintenance-reducing.)
Outline of what it should do
1. prints crucial Canvas module info: the installed version, the current schema it is at, and all post-update functions that have been applied
2. calls all relevant `CanvasConfigUpdater::needs*` methods to determine whether all Canvas config entities have indeed been updated (they might not have a post-update applied if config sync happened AFTER post-updates ran)
3. iterates over all Canvas config entities (`AssetLibrary`, `BrandKit`, `Component`, `ContentTemplate`, `Folder`, `JavaScriptComponent`, `PageRegion`, `Pattern`) and validates all of them + prints the validation errors
4. iterates over all Canvas content entities (`Page`) and validates all their default revisions (and all translations in those revisions) + prints validation errors
5. same as 4, but now for _all_ revisions, not just the default
6. :grey_exclamation: Not necessary until Canvas again allows creating `component_tree` fields on other entity types such as `Node`s: ~same as 4+5, but now for all Canvas fields on any content entity type~
## Non-functional requirements
0. it must be available as a Drupal command, and should optimize for https://www.drupal.org/node/3584928 — it's okay if it's is a >=11.4-only feature
1. it must not assume that everything can be validated in a single PHP execution (typical PHP `max_execution_time`: 30 seconds): assume it may take anywhere between 1 seconds and 24 hours
2. it must be safely interruptable
3. it must continue from where it last ended (either because it _finished_ validating a given subset, or because it was _interrupted_)
4. it must be parallellizable when called from CLI (by spawning child processes); this is how it can be sped up
5. it is a CLI tool, but it must also be able to power a web UI: #3588907+, which means both the results and the code to generate the results must be callable from there (assume Drupal's Batch API would generate it)
6. it must be able to reliably and granularly detect which entities need revalidating: a single entity being changed should not require re-scanning everything
7. it must have a built-in mechanism to try to hit a given time window (e.g. 1 minute), to automatically spin up as many child processes (within a given process count limit) as needed to try to hit that time window
issue