Add ESLint flat config support

[BePo65]

Added support for eslint 'legacy' and 'flat' configuration files.

The recommended configuration is used for the new flat configuration. The recommended configuration for the legacy system is renamed to recommended-legacy (as recommended by the eslint documentation).

(see #378 (comment))

[Turbo87]

this PR seems to contain a bunch of unrelated changes that should probably go into dedicated PRs

[BePo65]

The point is that eslint v9 is a breaking change: the configuration system switched from 'legacy' to 'flat'. As a consequence, you cannot simply run the unit-tests with eslint@9.x installed; you will have to provide a flat configuration file.

As a consequence, we have to change the tests in the ci workflow that use different versions of eslint. For that I created the "tests for all supported eslint versions".

As another consequence, we cannot simply use eslint@9.x in the plugin project, because in that case, we would have to change the eslint configuration file to a 'flat' format (at least as long as you don't set the ESLINT_USE_FLAT_CONFIG environment variable - see documentation).
On the other hand, chai@5.x requires an esm environment - what we don't have.
To prevent these problems I added the 'Prevent renovate to update to esm releases of 'eslint' and 'chai'' commit.

Probably we could use this version of the plugin even with eslint@2.x, but if someone would try to use the recommended configuration, this would be a breaking change anyway (because the legacy configuration is called recommended-legacy (as recommended by the eslint documentation).
So the idea was to drop the tests for the very old eslint versions. And as eslint@7.x requires node v16.x, why test with older node versions (but not with the current one)? Of course you may come to another conclusion 😄 .

So it's your decision: what commits should I move to another pr. I will gladly change anything you want.

[BePo65]

Before I forget it; one more comment:
the version number in the meta tag of the definition of the plugin must equal the version number of the package.

I didn't find a script that sets the vx.y.z tag of a branch (used for triggering the publishing of a new release). If there is a script that sets this tag, this could be a place to update the version not only in the package.json file.

[BePo65]

So now I moved the changes that are not related to the addition of the flat configuration to new pr (#380 and #381).

As eslint v8 and v9 using a flat configuration file require different configs than the older versions, I had to split up the ci workflow tests with all major eslint versions into 2 different sequences.

I hope the current structure conforms better with your ideas 😄,

[BePo65]

So now this pr is ready to be merged.

BTW: thank you for making me a collaborator - it's an honor for me.

[Turbo87]

I've found a way to use the existing test suite even with ESLint 9 (see #388), which means we don't have to duplicate all of the test files, making the code base much more maintainable. I've thus removed all of the additional test setup in this PR, leaving only the config changes.

Since the only breaking change in this PR is the rename of the recommended config, I've decided that it would probably be sufficient for now to export a recommended-flat config and keep the recommended config as-is. This allows us to release this in a minor version, because there shouldn't be any breaking changes in this PR anymore.