Add linting for custom markdown syntax

[GuySartorelli]

Initial linting was added in silverstripe/developer-docs#11 but excluded linting our custom markdown.

We have custom markdown syntax as documented in extended markdown syntax.

These need to be linted to avoid potential rendering errors, such as using an invalid callout block text (e.g. > [!SOMETHINGINVALID], trying to add text on the same line as the callout block header, forgetting to add space around either of these blocks, or trying to use an option that doesn't exist for the children block.

Acceptance criteria

• Callout blocks are linted
  • Must not have any content on the same line as the header
  • Header must be one of the ones documented on the contribution page
  • Callout blocks must not be added inside another callout block, or a blockquote
  • Check if they render correctly in a table - if they don't, they must not be added there either.
• Children blocks are linted
  • Must have an empty line before and after the children block
  • Children block must not span multiple lines
  • Must not have any other content on the same line as the children block
  • No unnecessary spaces are inside the children block
  • No unexpected options are used inside the children block
  • Children blocks must not be added inside a callout block, a blockquote, a list, or a table (basically, these can't be inside any block element other than a paragraph)
• relative links (i.e. links to additional docs pages) are linted
  • Always include a trailing slash (if there's an anchor, the trailing slash is before the anchor)
  • Always start from / or be at the same level as the current page (i.e. no ../my_page)
  • Page being linked to must exist
  • If there's an anchor, the anchor must exist on the page being linked to
  • No absolute URLs (unless we're explicitly intentionally linking to docs from a different version - those should use an HTML comment to skip the linting rule for that URL)
• API links are linted
  • Don't use the shorthand [api:MyNamespace\MyClass] - always use [`MyClass`](api:MyNamespace\MyClass)
  • Validate the syntax for the api link is correct (e.g. use MyNamespace\MyClass->propertyName for properties and config - never MyNamespace\MyClass.configName)
  • No absolute URLs
  • code in the text part of the link has backticks (e.g. [MyClass](api:MyNamespace\MyClass) is invalid, use [`MyClass`](api:MyNamespace\MyClass) instead)