feat: Add eslint/core package

[nzakas]

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request?

This package creates the @eslint/core package, which is the future home of the runtime-agnostic rewritten core of ESLint.

Right now it just exports types for language plugins.

What changes did you make? (Give an overview)

• Created the packaged
• Updated the release-please script
• Created type definitions

Related Issues

fixes #62

Is there anything you'd like reviewers to focus on?

I wasn't sure if we should be testing the type definitions somehow? I'd defer to someone with more TypeScript knowledge than I on how that might be done.

[JoshuaKGoldberg]

[Docs] Following #52, it'd be good to have a decision doc for licensing. Even if it's just "we need / want to use the same as existing ESLint licenses".

[nzakas]

There was no decision made. The OpenJS Foundation says any new projects must be licensed under Apache 2.0.

[JoshuaKGoldberg]

Is there a source that can be linked?

[nzakas]

Linked from where?

And I have no idea. We've been part of the foundation for a long time and this was communicated early on.

There might be something somewhere in https://github.com/openjs-foundation if you feel like going on a search.

[JoshuaKGoldberg]

Linked from where?

Proposal: a decision doc, for visibility?

[JoshuaKGoldberg]

(posting some quick comment-questions in lieu of a full review)

[JoshuaKGoldberg]

Following #52 and #73: I don't feel able to review this file without understanding how this is meant to play with @types/eslint over time. Is it intentionally different? Have the tradeoffs been discussed somewhere?

[nzakas]

We weren't consulted on the creation of @types/eslint, so I consider those to be non-canonical types. As we move forward, we'll be creating types the way we want and using those. Maybe @types/eslint will get smart and start importing our types to flesh out the package, but either way, I'm not going to worry too much about it.

[JoshuaKGoldberg]

non-canonical types

Practically speaking, those and typescript-eslint are canonical types, as those are what the entire community uses at the moment. If the decision is to explicitly not attempt backwards compat, sure, that's a reasonable decision - but I don't think they can be ignored in decision-making summarily.

[mdjermanovic]

LGTM, thanks!