feat: add checks for docs validations

[stevenle]

screenshots:

fixes #722

[jeremydw]

1. Before we give users the ability to define custom checks we might want to iterate a bit on the UI / structure of the checks API. So maybe we only define internal checks for now before giving users the ability to do custom checks?

[For example, we might want to provide a few built-in UI components (e.g. table, accordion, side-by-side comparison, etc.) that checks results can populate. For example, a translations check might want to output a table, a typo check might want to output a list (with each item linking to a field), Lighthouse or AI-assisted check might want to add a screenshot, etc.)]

2. I think we need a way to limit checks to run on specific collections. For example I might have custom checks for pages that I don't have on global modules, vice versa.

(I would say point 2 is more important than 1 right now)

[stevenle]

1. Before we give users the ability to define custom checks we might want to iterate a bit on the UI / structure of the checks API. So maybe we only define internal checks for now before giving users the ability to do custom checks?

[For example, we might want to provide a few built-in UI components (e.g. table, accordion, side-by-side comparison, etc.) that checks results can populate. For example, a translations check might want to output a table, a typo check might want to output a list (with each item linking to a field), Lighthouse or AI-assisted check might want to add a screenshot, etc.)]

realistically we're the only users of this for now so i think it's fine exposing this api and even changing it later. i can add a docstring that says we're still iterating on the final api/interface for the checks configuration if that eases your concerns. do you have suggestions on how to add those more rich types of components? i personally would be fine with just enabling markdown and having the plugin provide a landing page for the more detailed error mesages.

2. I think we need a way to limit checks to run on specific collections. For example I might have custom checks for pages that I don't have on global modules, vice versa.

(I would say point 2 is more important than 1 right now)

any suggestions? e.g. {collectionsEnabled: ['Foo'], collectionsDisabled: ['Bar'] ?

[jeremydw]

1. sgtm
2. for the allowlist, maybe something akin to a glob pattern? (similar to what we were doing with schema.glob). know it's not a perfect analogy, but maybe something like this:

// for just pages
collections: ['Pages'],

// for all collections (omit it, by default it's enabled for everything)

I can't think of a scenario now where it would make sense to have something apply to all collections but be disabled in specific ones, so maybe we just go with collections for now?

[stevenle]

done

[jeremydw]

no action needed here just noting we really need to extract the extract function into a shared file so that all our callsites can use it. i think the one in our internal localizer plugin is currently the most comprehensive so i'll take an AI at adding that in a PR for us