Handle rule configuration errors more consistently

[not-an-aardvark]

I've noticed that our error-handling strategy is very inconsistent across different error scenarios. This inconsistency is a problem because it creates unexpected edge cases in integrations (causing bugs like eslint/archive-website#413).

Problem	Current error-handling behavior
Unrecognized rule in config file	Linting error
Invalid rule config in config file	Fatal error
Invalid rule config in Linter#verify	No error
Unrecognized rule in /* eslint */ comment	Linting error
Unparseable rule config in /* eslint */ comment	Linting error
Parseable, but invalid rule config in /* eslint */ comment	Fatal error
Unrecognized rule in /* eslint-disable */ comment	No error

I've italicized the cases that I find particularly surprising (namely, that linting can continue if an /* eslint */ comment contains a parsing error, but the process crashes if the rule config is parseable and doesn't match the schema). It seems like an unparseable rule config should always be a more severe issue than an invalid rule config, because all invalid rule configs are parseable.

This is also strange because Linter#verify doesn't verify rule schemas at all, so it ends up that only inline config schemas are verified, not the main config being used for the file.

I think we should make invalid rule configs in /* eslint */ comments into a linting error, rather than a fatal error. That would create a useful invariant where Linter#verify should never throw an error when given a valid config, regardless of the source text being linted.

Separately, I think we might want to reconsider #8325 (validating configs in Linter#verify). There were two objections brought up before: performance and separation of concerns.

• I don't think performance would be a problem in practice, because we could cache config objects and avoid validating them again if we see a config which is known to be valid. This would prevent CLIEngine from slowing down.
• Linter already validates rule schemas anyway for inline comments, so I don't think validating the top-level config would introduce any new issues relating to separation of concerns that aren't already present.

[mysticatea]

Sounds reasonable to me.

Our online demo does not work silently in the "Parseable, but invalid rule config in /* eslint */ comment" case. Because it's a problem in source code, it should be linting error rather than fatal error.

[mysticatea]

I re-labeled as a bug because ESLint crashes by the content of source code.