Allow including / excluding individual checks by key

[AlexRiina]

This pull requests allows the end user to include or exclude individual tests as part of the config file. I was using this to lint a file where my markdown pipeline automatically converted ellipsis and quotes to their nicer html entity equivalents. Prior to this pull request, I could only disable the entire typography.symbols suite but my pipeline would not automatically convert a (c) so I didn't want to disable the whole suite.

Resolves #729. Resolves #491. Resolves #1091.

[Nytelife26]

This is a very interesting proposition. At present the config does only allow enabling or disabling modules, rather than specific sub-checks. How do we feel about this, @suchow?

[suchow]

First, there are three interrelated issues here:

1. Proselint isn't Markdown-aware and so complains about syntax that's acceptable in Markdown but not in prose (e.g., ... vs. …). To sidestep this issue, @AlexRiina wanted to disable only some of the typographic checks. But we should also fix the underlying problem. I think there's an issue open for this already, somewhere; people run into it all the time.

2a. There is no mechanism to disable only some of a module's checks.

2b. If we create a mechanism to disable only some of a module's checks using the proposed approach, it's quality will depend on how well we are using the check namespace, breaking modules down into logical submodules that people would want to independently turn on and off.

I'm 👍 on allowing enabling/disabling submodules via the config and think it'll be useful to many people. I'm agnostic as to whether the current PR is the "right" way to do that; I defer to you. I think we should, perhaps as part of this PR or as a follow-on PR, review the whole namespace and see if there's anything obvious that should be renamed, split, or combined.

[Nytelife26]

It seems like that largely depends on namespacing, then. I believe this should be resolved *after* our categorization evaluation, rather than before. Therefore, we should postpone this for later in my opinion.

[Nytelife26]

It occurs to me that actually, there is a more sensible way to do this. Many of our checks are formatted like so: check.subcheck. There is never any check.subcheck.subsubcheck. Why, then, are we grouping several subchecks into one file?

An easy way to solve this would be to make them individual, as they should be.