[cumulative docs] Identify opportunities for automation and linting

[colleenmcginnis]

Context

In #1614 we added a bunch of new guidance for writing cumulative documentation including applies_to usage and placement. These guidelines are quite complicated. I think there are opportunities to build some automation and/or linting rules that could help us provide guidance in context at build time and reduce the amount of content docs contributors need to read and internalize.

Opportunities for automation / assertions

• Sort applies_to badges. This is already in progress:
  • Within a single key in applies_to, always order versions from newest to oldest (docs-builder#1726)
  • Across all keys in applies_to, always use the same order for keys (docs-builderUpdate applies_to Stack/Serverless/Deploy/Product render order #1727)
• Sort tabs with applies_to. This is dependent on Support applies_to in additional directives/components #1436.
• Render applies_to badge at the beginning of a list item regardless of where it is added in the source.
  • Note: I'm not sure if we actually want to do this or if we should just lint for badges that are not at the beginning of a list item and prompt the contributor to move the badge via a hint or warning.
• Render applies_to badge at the beginning of a paragraph regardless of where it is added in the source
  • Note: I'm not sure if we actually want to do this or if we should just lint for badges that are not at the beginning of a paragraph and prompt the contributor to move the badge via a hint or warning.
• Throw a warning on section applies_to in h1 (title)
  • Use applies_to in the frontmatter instead
• Throw a warning on inline applies_to in h1 (title)
  • Use applies_to in the frontmatter instead
• Throw a warning on inline applies_to in any h2+ (Warn when a heading contains an inline applies_to #1777)
  • Use section applies_to instead

I'll keep adding more as needed.

cc @theletterf (since we talked about this a bit)