test: Enable a few good typescript-eslint rules

[samestep]

Description

This PR enables a few good typescript-eslint rules:

• @typescript-eslint/no-base-to-string catches a bunch of places where we try to stringify things that would just show up as "[object Object]"; I didn't have the bandwidth in this PR to fix these so I just set this rule to "warning", but they are all genuine bugs as far as I can tell
• @typescript-eslint/no-confusing-void-expression might be a bit more of a stylistic thing, but I think it's pretty good for clarity
• @typescript-eslint/no-unnecessary-boolean-literal-compare didn't surface much, but it seems like a good thing to have enabled
• @typescript-eslint/no-unnecessary-condition surfaced a bunch of bugs and also a bunch of things that are due to us using the type system poorly; again I didn't have the bandwidth here to fix all these so I just made it a "warning", but this is very good to have enabled
• @typescript-eslint/prefer-ts-expect-error doesn't actually affect anything currently, but it is quite good so I'm enabling it proactively

Checklist

• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new ESLint warnings
• I have reviewed any generated changes to the diagrams/ folder

[cloudflare-pages]

Deploying with    Cloudflare Pages

Latest commit:	d3e2ead
Status:	⚡️  Build in progress...

View logs

[codecov]

Codecov Report

Merging #969 (d3e2ead) into main (ea8d9f4) will increase coverage by 0.07%.
The diff coverage is 58.06%.

@@            Coverage Diff             @@
##             main     #969      +/-   ##
==========================================
+ Coverage   63.23%   63.30%   +0.07%     
==========================================
  Files          62       62              
  Lines        7918     7906      -12     
  Branches     1837     1829       -8     
==========================================
- Hits         5007     5005       -2     
+ Misses       2790     2781       -9     
+ Partials      121      120       -1     

Impacted Files	Coverage Δ
packages/core/src/contrib/Utils.ts	31.03% <0.00%> (+1.52%)	⬆️
packages/core/src/renderer/Path.ts	10.12% <0.00%> (+0.12%)	⬆️
packages/core/src/synthesis/Synthesizer.ts	28.19% <0.00%> (+0.06%)	⬆️
packages/core/src/utils/Util.ts	54.78% <0.00%> (+0.47%)	⬆️
packages/core/src/utils/CollectLabels.ts	66.31% <60.00%> (+0.33%)	⬆️
packages/core/src/compiler/Style.ts	78.88% <100.00%> (-0.05%)	⬇️
packages/core/src/engine/Autodiff.ts	81.85% <100.00%> (+0.03%)	⬆️
packages/core/src/engine/EngineUtils.ts	64.96% <100.00%> (ø)
packages/core/src/engine/Evaluator.ts	33.33% <100.00%> (+0.35%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ea8d9f4...d3e2ead. Read the comment docs.

[cmumatt]

Looks amazing -- I love these kinds of changes! Thanks for doing this hard work to improve the codebase now and in the future. Do we need to log an issue so we go back and clean up any remaining warnings and change the mode from warning to error?

[samestep]

Do we need to log an issue so we go back and clean up any remaining warnings and change the mode from warning to error?

Hmm we can; the thing is, a lot of the things we have set to "warning" would take a significant amount of refactoring effort to change, because they result from systematic typing deficiencies in our architecture. If we do end up resolving them to the degree that we can actually change the mode to "error", that would just be a side effect of a much larger effort.