Describe your suggestion

The current way of testing markdownlint custom rules is functional but not the most ideal. Ideal would be automated tests with a runner and against assertions, but until now has been a low priority thing due to potential complexities in testing CLI stuff with third-party libraries.
Fortunately, there should be a way forward via child processes.

Pros

• Means CI can always runs all relevant tests if a custom rule has changed, even if the PR does not touch any of its test files (as currently, it only lints changed files).
• Tests do not need to be manually run by running the linter on test files (ties into previous point as well).
• Successful intentional failures can be reported as passes, not failures. Easier to grasp the test outcome.

Acceptance criteria

• Use Node built-in test runner for tests for all custom rules
• Ignore custom rule markdown files in lesson linting GH workflow
• Write GH workflow for custom rule tests