eslint: DOCSTRING COP

[boneskull]

Because docstrings are now the single source of truth for command documentation (along with types), we need to ensure they are high-quality and normative.

This means establishing baselines for the bare minimum expected in a docstring, as well as the way to do it in cases where there are multiple options. Some examples:

• establish a single style of inline link
• forbidden tags, if any (e.g., @description), and exceptions (@description when @summary is present)
• conventions for the tags we use, if needed (the correct use of the @example tag particularly needs documenting)
• must have tag x, should have tag y, and can have tag z

...and we need a workflow so we can maintain the standard.

ESLint is probably the right way to do this. There are some that work with docstrings and jsdoc-like tags. TypeScript itself will handle any type-related problems, but can't otherwise tell you that you're using a TypeDoc tag wrong.

We can probably find an ESLint plugin to get us at least partway there. Best case is that we can use an off-the-shelf plugin and configure it to our liking. Worst case is from-scratch ESLint plugin. If research yields the worst case, I'd probably just forget about it.