Currently, the ESLint configuration file is top-level but only files
under src/ are linted according to the npm script. This is a bit
disjoint.

Two options:

1. Move all usage of ESLint to src/.
2. Work towards applying ESLint to all files in this project.

I'm going with (2) since there are some unlinted files that could
benefit from linting. The first step, done by this commit, is to update
the npm script and specify the unlinted files explicitly in
.eslintignore (also removing unused ESLint exceptions from these files).
Future commits will continue in this direction.

This was added in 55f4842 for context
of where the initial rules came from. The rules have since deviated from
the linked configuration file.

The extension-less configuration file name was deprecated more than 5
years ago¹, and the deprecation message is no longer present in the
official documentation.

Even though the extension-less file still works fine, the rename serves
to keep up-to-date with documented formats and make it clear to some
text editors that YAML is the format used in this file.

¹ https://dev.to/ohbarye/eslintrc-without-file-extension-is-deprecated-3ngg

The Airbnb base config was presumably adopted early on with good
intents, but over time the ESLint config file has become littered with
overrides to disable many rules enabled by this base config.

To me, it seems the main reason is that the Airbnb base config includes
both code-quality rules and code-style rules, while we have chosen to
ignore most code-style rules.

The "recommended" base configs mostly¹ set code-quality rules. Using
these as a replacement for the Airbnb base config means much of the rule
overrides are no longer necessary.

Note: some new overrides were added to avoid code changes. These will
be addressed in subsequent commits.

¹ eslint:recommended enables `no-mixed-spaces-and-tabs`, which is
  probably fine. https://eslint.org/docs/latest/rules

Files in these directories should be held to the same standards as files
in src/.

I can no longer find ESLint 7 rules documentation on the official
website¹. The upgrade doesn't introduce any breaking changes for current
usage, and now (while going through rules) would be a good time to
upgrade. This will make it easier to reference rule doc pages in
subsequent commits.

¹ https://eslint.org/docs

Lexical declarations (let/const/etc.) are discouraged in case blocks
since they are accessible to the entire switch block (unless scoped by
curly brackets).

None of the impacted declarations are currently used outside of their
case block scopes, so all that's needed here is to add curly brackets.

Rule doc page: https://eslint.org/docs/latest/rules/no-case-declarations

This is scoped to usages of the same pattern in one file. Two options:

1. Ignore the lines explicitly rather than across the whole project.
2. Apply the alternative from the rule doc page.

Going with (2) since it seems reasonable.

Also added a link to the actual bug since it took some time to dig that
up.

Rule doc page: https://eslint.org/docs/latest/rules/no-compare-neg-zero

There is just one, which can be wrapped in parentheses to make it valid.

Rule doc page: https://eslint.org/docs/latest/rules/no-cond-assign

The recommendation to use `Object.prototype.hasOwnProperty.call()` is
already used elsewhere in this codebase, so I assume these deviations
were due to unintentional oversight.

Rule doc page: https://eslint.org/docs/latest/rules/no-prototype-builtins

Since the existing unused variables have somewhat meaningful names, add
underscores to these names and configure the rule to allow underscore-prefixed
names to be unused.

This commit does not address unused imports and functions - those are
temporarily disabled by line and will be addressed in following commits.

node-fetch is no longer necessary as a direct dependency. Move it to
devDependencies since it is still used in a test.

Keep the direct dependency since it is still used in
src/util/parseMarkdown.js.

The only usage was removed in a7bfd62.

There are better ways to address these (componentWillMount¹,
componentWillReceiveProps²). I opted for the rename to avoid complex
code changes.

¹ https://legacy.reactjs.org/docs/react-component.html#unsafe_componentwillmount
² https://legacy.reactjs.org/docs/react-component.html#unsafe_componentwillreceiveprops

There is only one, so disable it for the specific line. A proper fix
will come in the following commit.

This was added in 8a213ac but the usage
was removed in 43ee2ed.

Move other lines closer to where they are used.

Previously when missing, it defaulted to "latest" and showed a warning.

No code style rules yet but they will be added in subsequent commits.

This takes advantage of configuration cascading¹ so rules that only
apply within src aren't applied elsewhere.

¹ https://eslint.org/docs/latest/use/configure/configuration-files#cascading-and-hierarchy

James went through all the rules that we had custom-enabled prior to
b3cedb7. These are the ones that were
flagged to be re-added.

Some are commented out since there are existing violations. Subsequent
commits will un-comment the rules and address violations.

Co-authored-by: James Hadfield <hadfield.james@gmail.com>

There is only one, and it is because a function expression is used
before it is defined. Changing to a function declaration solves this
because those are hoisted to the top-level (function expressions are
not).

Rule doc page: https://eslint.org/docs/latest/rules/no-use-before-define

As the rule doc page says, if a variable is never reassigned, using the
const declaration is better.

Rule doc page: https://eslint.org/docs/latest/rules/prefer-const

This was already disabled from 910e567
and it looks like there's enough context to keep it as-is.

Rule doc page: https://eslint.org/docs/latest/rules/no-unneeded-ternary

These seem fine to have, so disable the rule per-line.

Rule doc page: https://eslint.org/docs/latest/rules/no-console

The last reference was removed in
5d63682. This doesn't show up as
"unused" during linting since it's possible that downstream code could
import this function, but I don't think we have to worry about that for
this specific function.

This is enabled in the Airbnb base config¹ that we previously used. It's
still useful to have around.

It can be disabled for the violation in title.js since using indexes as
keys is only discouraged if the order of items may change² (not
applicable here).

¹ https://github.com/airbnb/javascript/blob/7982931ba745c0f57ba6934fc7e6cc43901dac76/packages/eslint-config-airbnb/rules/react.js#L388
² https://legacy.reactjs.org/docs/lists-and-keys.html#keys