feat!: drop Node 12/17 support

[bmish]

Goal is to match upcoming ESLint v9 core Node version support:

https://github.com/eslint/eslint/blob/845c4f40274ccb3727c624db44c7a23aafa71318/package.json#L164

[eslint-github-bot]

Hi @bmish!, thanks for the Pull Request

The first commit message isn't properly formatted. We ask that you update the message to match this format, as we use it to generate changelogs and automate releases.

• The commit message tag wasn't recognized. Did you mean "docs", "fix", or "feat"?

To Fix: You can fix this problem by running git commit --amend, editing your commit message, and then running git push -f to update this pull request.

Read more about contributing to ESLint here

[nzakas]

Can you combine this with #133 ?

[bmish]

Just to explain my motivation here, I submitted these as two changes:

1. Drop Node versions
2. Upgrade dependencies

Because:

• Dropping Node versions is considered a breaking change while upgrading dependencies afterward is just a non-breaking feature/enhancement. I consider it good practice to isolate breaking changes from subsequent changes enabled by the breaking changes (of which there could be many).
• Both of these changes are relevant to consumers and deserve to be mentioned in the changelog, and I think it's nice to give each their own bullet point (by way of a separate PR) instead of trying to cram multiple into one.

[bmish]

@nzakas if we're considering generator-eslint package.json changes breaking but not the plugin template package.json, then I can split this into two PRs (one for each package.json), so we can release non-breaking changes first.

[nzakas]

I don't think there's much benefit to releasing non-breaking changes first. This package gets under 500 downloads a week, and people use it once and forget it, so we're not at much risk of breaking people's experiences. I'd say let's just merge everything and release it.

[bmish]

Fair enough. Then I think we can merge everything and do a major release.