Start a TS config file, add npm scripts, and add CI.

Typescript config is mostly via `tsc -init` and will be modified by
later commits.

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

Follow instructions for typescript-eslint¹, except the addition of
plugin:@typescript-eslint/recommended - that will come in a future
commit.

Instead, use plugin:@typescript-eslint/eslint-recommended to have
compatibility with the existing use of eslint:recommended².

Adjust existing rules to use @typescript-eslint counterparts.

¹ https://typescript-eslint.io/getting-started
² https://typescript-eslint.io/linting/configs#eslint-recommended

These weren't flagged as errors previously, however the previous commit
swapped the rule "no-use-before-define" to "@typescript/no-use-before-define".

These seem to be false-positives (the code works just fine in practice)
related to named exports. For instance, the following "works"
but fails linting:
```
export const a = () => b; // error: 'b' was used before it was defined.
export const b = 42;
```
This is an error even if we enable the "allowNamedExports" option - see
https://eslint.org/docs/latest/rules/no-use-before-define#allownamedexports

I don't know enough about specifications to know why this is considered
an error but still works in practice, however it's not much effort to
reorganise the code in this file.

This base config, strongly recommended by typescript-eslint¹, contains
code quality rules for TypeScript code.

Place it after eslint:recommended since this ruleset disables preceding
rules known to cause conflict. The previous base config is automatically
included with the new one² so it is a replacement rather than addition.

This exposes new linting errors - add rule overrides to document them
here and address separately in subsequent commits.

¹ https://typescript-eslint.io/linting/configs/#recommended
² https://typescript-eslint.io/linting/configs/#eslint-recommended

There is existing usage of assigning require to a variable, I assume for
good reason.

Rule doc page: https://typescript-eslint.io/rules/no-var-requires/

The base no-empty-function rule was not enabled by eslint:recommended,
however TS-eslint's recommended ruleset enabled it which surfaced
violations.

I opted to allow empty arrow functions since those are used already in a
few places. That leaves just one non-arrow function which I disabled as
an exception given presence of surrounding context for its existence.

This is recommended¹.

¹ https://babeljs.io/docs/babel-preset-typescript

For resolve.extensions and babel-loader.

For resolve.extensions specifically,

1. '...' is used to append to the default list¹.

2. The order of ts before tsx is somewhat intentional. Even though it
   doesn't make a difference here (in our currently limited use of
   TypeScript), others have reported that the order can matter for
   unclear reasons².

¹ https://webpack.js.org/configuration/resolve/#resolve-extensions
² https://stackoverflow.com/a/49708475/4410590

This will frame decisions made in subsequent commits.

Although there are other JavaScript files outside of src/, the initial
aim for TypeScript adoption in this project is scoped to the Auspice
package, whose project files fall under src/.

This allows TS files to import from JS files.

Don't set checkJs because JS files don't need to be type-checked.

Don't set maxNodeModuleJsDepth because there is no need to include JS
files from node_modules.

Default values suffice. Reasons:

- lib: We don't need anything outside of the default set of type definitions.
- experimentalDecorators: We aren't using experimental decorators.
- noLib: We aren't providing type definitions for primitives.

node_modules contains declaration files from dependencies which cause
errors when run through tsc. These errors are not relevant to compiling
Auspice code.

Setting skipLibCheck=true suppresses checking of *all* declaration
files, which is a common workaround¹ to remove the errors described
above. However, this includes custom declaration files in the codebase.
Even though there aren't any now, they might come later during
further TypeScript adoption.

An unset `types` setting is the reason why node_modules/@types is
included for compilation by default². Set it to an empty array since
there are no declaration files that need to be explicitly included here
yet. Also remove `typeRoots` since it is targeting the same thing as
`types`.

¹ https://stackoverflow.com/a/57653497/4410590
² https://www.typescriptlang.org/tsconfig#types

There's no good reason to check declaration files managed by TypeScript.

This also saves a fraction of a second during compilation.

More info: https://www.typescriptlang.org/tsconfig#strict

This passes now, meaning there isn't any unreachable code detected.
Enable this check so any unreachable code must be intentional.

This passes now, meaning there aren't any unused labels detected.
Enable this check so any unused labels must be intentional.

These all pass now. Enable them so any inconsistencies must be
intentional.

There are no symlinks in this project, so this is not necessary.

There are no module imports with a ".json" extension in this project, so
this is not necessary.

The default behavior seems fine - with the way include and allowJS are
set, this shouldn't have an affect anyways.

There are no expectations for global UMD exports in this project, so
this is not necessary.

There are no module references in this project that require a custom
base directory or path, so these are not necessary.

In the future, this *might* be applicable for the @extensions webpack
alias if files emitted by tsc are used instead of babel.

https://www.typescriptlang.org/tsconfig#isolatedModules

'node' is required for node_modules to be considered during an import¹.

¹ https://www.typescriptlang.org/docs/handbook/module-resolution.html#how-nodejs-resolves-modules

More as a proof-of-principle, but even using a lot of `any`-types is an
improvement over the previous code.

@types/node must be installed and "node" must be added to types so that
"process" can be understood.

"noPropertyAccessFromIndexSignature" must be disabled so that
`process.env.EXTENSION_DATA` can be used without error.

This requires bumping react-i18next to v11.15.6, the earliest version to
contain a bug fix for TypeScript ≥ 4.6¹.

¹ i18next/react-i18next@306e03a

This is a band-aid fix to an issue with tsc on src/map.js using
leaflet-gesture-handling's TS declaration file, which requires leaflet
types that are not provided by the leaflet package.

See this GitHub PR discussion¹ for a complete explanation and
alternative solutions.

¹ #1450 (comment)