Convert to major web app and API components and interfaces to TypeScript

[carlgieringer]

As of 2022-12-29, a little over 1/3 of the repo is TS. 🥳

• Lines JS: 37559
• Lines TS: 20762

At this point, we should identify any important remaining risky conversions, and leave the remainder for gradual conversion.

Good candidates for remaining conversion:

• A DAO (Justifications DAO is the most complex.)
• The entities reducer, which is large, complex, and fundamental to front-end consistency.
• The API handler and router, so that we can have some full-stack TS paths.
• JustificationsService and associated services because of their complexity.
• Files that are imported into a lot of other files, such as general.js or files with util in their name.

Also review TODOs on this issue in the codebase and decide if they should be new issues.

[carlgieringer]

After #232, codebase will be 54% TS:

• JS: 26846
• TS: 31413

[carlgieringer]

This issue was originally "Convert to TypeScript", but then I realized that 100% TS conversion would take a long time, and I want to focus on functionality. We can convert the remaining code on an as-needed, as-touched basis. All new code must be style-conformant TypeScript.

After #240, I believe that all major components and flows have examples in TypeScript:

• Client
  • Client routing
  • Client editors, including:
    • reducers and sagas
    • form input validation and submission validation
  • Redux reducers/slices
  • Sagas
  • Client components
  • Action creators
  • API action creators
• API:
  • API gateway handler
  • API routing
  • API route definition, request validation, and route handlers
  • Our service locator (AppProvider/ServiceProvider)
  • Services, including input validation (JustificationsService, our largest
  • DAOs, including JustificationsDao, our largest and most complex DAO and orm.ts, our row-to-data conversions.

The known remaining big rocks are:

• The browser extension (Convert most of the browser extension to TypeScript #251): I didn't type this at all yet. I forget how (or whether) that's bundled, so we might need build considerations there.
• Independent lambdas, like justification-scorer and proposition-tag-scorer (Remove major type-related risk from independent lambdas #252). I think these use gulp instead of esbuild, so there might be additional build work there.
• TextSearcher/full-text search: Convert TextSearcher to TypeScript #296
• The entities reducer. I am not 100% sure that this reducer will remain in its current form, since e.g. normalizr is in maintenance mode (although probably will be adopted/forked by redux-toolkit if necessary) and redux-toolkit offers wrappers ('entity adapters') that the normalizr fork would probably gravitate towards supporting.
• AwsLogger: this class is overflowing with dynamic JS object stuff, and so is difficult to type. At the same time, I'm not sure if there's a great benefit to typing it, since we can just provide an interface that matches the output of the dynamic work.

Another way to identify potential candidates for conversion is to run bin/line-count-tree-map.sh and inspect it for large JS files.

The current status of the conversion is:

• 26,894 JS lines vs. 31,646 TS lines = 58,540 total JS/TS
• So 54% TS. A majority 🥳