Replace eslint with biome

[jankapunkt]

Summary

Replaces eslint with biome with remains compatible with commonjs and is also able to handle (future) esm (see #279)

Please do not get scared of the change files. While the linter only produced warnings, the formatter produced lots of errors, which were automatically fixable (similar to how prettier works)

Linked issue(s)

#403 #279

Involved parts of the project

• all JavaScript code
• CI

Added tests?

• none

OAuth2 standard

• none

Reproduction

clone and run one of the following:

npm run lint
npm run lint:fix
npm run format
npm run format:fix

[Copilot]

Copilot wasn't able to review this pull request because it exceeds the maximum number of lines (20,000). Try reducing the number of changed lines and requesting a review from Copilot again.

[dhensby]

I don't feel too strongly one way or the other for biome vs eslint; I'd slightly lean towards eslint due to familiarity, native JS and maturity, but it's not a show stopper.

Feedback:

1. I ran biome locally and got some changes, which I'm not sure if we want or not given that it means if some other contributor runs biome lint --write then they will get quite a big diff which isn't committed and could cause noise in other PRs.
2. You've moved from spaces -> tabs, and single to double quotes. Both changes create significant diff noise, personally I'd keep the current formatting conventions where possible to reduce this noise - but not a deal breaker; we could also add a .git-blame-ignore-revs file that can hide these reformat changes from blames to keep disruption down due to formatting changes.
3. I'd reword some of the commits (a bit pedantic, sorry):
   a) feature(dev): replace eslint with biome toolchain: chore(deps-dev): ... is typical for this kind of change
   b) fix(core): biome format fix: stype: ... "fix" commits tend to be for fixing bugs, this is just internal code reorganisation so not worthy of fix commit IMO
   c) fix: run biome formatter is docs: add biome badge
   d) fix run biome formatter fix: style: again, I'd probably fixup into the previous refactor commit
   e) fix(tests): detect different line in emitted error after biome formatter fixes: test: ...

[dhensby]

• Should we split out the other dep bumps (type-is, mocha, sinon, vitepress) to their own commits or PR?
• Runnint npm run lint:fix creates a lot of changes (when I ran it locally anyway), which I don't think it should otherwise (as I said previously) other contributors will find themselves with a lot of noise when running this command.

[jankapunkt]

Thank you @dhensby I mostly did this because we are stuck at eslint 8.5 and can't move any further since eslint 9 requires ESM (see #279) and it is not the eslint we used to know because they splitted a lot of the rules from the core and it feels like a hot mess.

For the spaces and single quotes I am sorry to have missed that, my goal was to configure biome to be on par with our current code style as much as possible. I will change them to spaces and single quotes ofc.

[jankapunkt]

@dhensby I disabled some more rules to avoid lint fix creating noise. We can gradually enable / configure these rules in future PRs to get a coherent formatting that complies with many modern codebases out there.

Regarding the commit messages I would opt for squash merge to avoid polluting the git history.

[dhensby]

The arrowParentheses rule is also adding parentheses in places it wasn't. I'm actually a fan of them, so not so bothered, but depends if we want to try and keep consistency with what we have.

[dhensby]

Suggested change

	"trailingCommas": "none",
	"trailingCommas": "all",

Trailing commas "all" is biome's default and also appears to be what we already have in place; I'm also a big fan because it keeps diffs less noisy when adding new items