Add linting of source in markdown files

[mkaz]

Description

Adds eslint-plugin-markdown and the new command lint-md This allows for linting of code blocks that are marked js, javascript, or jsx, if a code block is not marked as such it should be skipped.

At the moment this uses the same base eslint rules, however we probably will want to adjust these rules for documentation. Most code blocks in documentation are snippets and incomplete chunks of code, so a fair amount of the current errors are due to no-unused-vars and no-undef rules. For example, a chunk of code might show how to set something, but not necessarily using what is set.

The first run through all docs:

✖ 2103 problems (2090 errors, 13 warnings)

How has this been tested?

1. Test by applying this PR
2. Run: npm install to install new packages

To run across all documentation:
3a. Run npm lint-md

To run across a single file:
3b. $(npm bin)/wp-scripts lint-md docs/designers-developers/key-concepts.md

Types of changes

1. Adds new script lint-md to wp-scripts
2. Adds eslint-plugin-markdown js package
3. Adds new command lint-md to main scripts

Next Steps

We probably want to test out and adjust the rules to make sense for documentation.

Once we get it to a decent config, we can run it against the docs and fix up code that needs fixing and then include in the CI builds.

[ntwb]

Nice, and FYI, I’m working on the coding standards docs in https://github.com/WordPress/wpcs-docs repo (No pull request yet, working on it locally) and will be creating a new package here @wordpress/remark-config for a shared config for Remark Lint to ensure markdown is compatible with the w.org handbooks and will plan on adding it also to @wordpress/scripts

[ntwb]

Further, I’ll look at what stylelint options are available to support listing CSS & SCSS in markdown files too

[gziolo]

This is great, thanks for opening it.

[gziolo]

I think this PR addresses #12426, well at least the part for linting markdown.

At the moment this uses the same base eslint rules, however we probably will want to adjust these rules for documentation. Most code blocks in documentation are snippets and incomplete chunks of code, so a fair amount of the current errors are due to no-unused-vars and no-undef rules. For example, a chunk of code might show how to set something, but not necessarily using what is set.

It might end up with having two ESLint configs for wp-scripts, since we will need to disable some rules. I would say, let's start simple and disable the noisiest errors and evaluate later the next steps. I'm thinking in terms of a follow-up PR, to be clear.