Finish eslint implementation by changing last few rules from `warn` to `error`

[bcolloran]

We have 6 eslint rules that are still set to only warn, but we want to get them all up to error. They are:

• [ ] @typescript-eslint/no-explicit-any -- this one will be a lot of work, and I'm not sure there is an easy path here, but we want to get there eventually
• [x] https://github.com/rilldata/rill-developer/issues/331 @typescript-eslint/no-unused-vars -- this should be a simple eslint auto fix
• [x] https://github.com/rilldata/rill-developer/issues/332 prefer-const -- this should be a simple eslint auto fix
• [ ] https://github.com/rilldata/rill-developer/issues/333 @typescript-eslint/ban-ts-comment -- this rule is only violated in a couple places, but it needs to actually be assessed for potential impact
• [ ] https://github.com/rilldata/rill-developer/issues/334 no-useless-escape -- this rule is only violated in a couple places, but it needs to actually be assessed for potential impact
• [ ] https://github.com/rilldata/rill-developer/issues/335 typescript-eslint/no-empty-interface -- this rule is only violated in a couple places, but it needs to actually be assessed for potential impact

We should probably handle each of these items in a separate PR. A successful PR will fix all the violations of the rule and delete the line for the rule in question from .eslintrc.cjs (deleting the line will switch the rule to to the default error state). If the tests pass and CI passes, we're good to go.

@AdityaHegde, I think you should probably take @typescript-eslint/ban-ts-comment, no-useless-escape, typescript-eslint/no-empty-interface -- there are just a few violations of each of these rules, so it should be quick, but these are the ones that could benefit from your experience in the code base.

@typescript-eslint/no-unused-vars and prefer-const can be done by anyone. These should just be quick tasks.

For @typescript-eslint/no-explicit-any -- there are a ton of places in the code where we're using any rather than a concrete type. There is no quick fix for this, and it will need to be a team effort. I'm not even sure what the right approach is for this, so we should decide how we want to handle that as a team.