chore: Set up release-please

[btmills]

This configures the release-please action for generator-eslint. As we merge changes using Conventional Commits formatting, release-please will create and update a pending release PR. That PR will contain a changelog of any commits merged since the prior release. When we're ready to do the release, we'll merge that PR, and the workflow in this PR will update the changelog and publish the release to GitHub and npm.

Separate from the code in this PR, I had to take a few manual steps:

1. Create a new npm granular access token.
   1. Name it release-please $package-name release-please.
   2. Choose a reasonable expiration. I went with 365 days.
   3. Under Packages and Scopes > select "Read and write" access > select "Only select packages and scopes" > select the package that we're setting up. "All packages".
   4. The token should not have Organization access.
   5. Generate the token.
2. Copy the generated token as a new repository secret new organization secret named NPM_TOKEN, and give access to the desired repository. If the token already exists, edit it to include access for the desired repository.
3. Edit the four Twitter API organization access tokens to grant access to the repository.
4. In the repository's Actions settings, under "Workflow permissions", ensure "Allow GitHub Actions to create and approve pull requests" is checked.
5. In the package's npm settings, change publishing access to "Require two-factor authentication or an automation or granular access token".

[btmills]

GitHub Actions workflows are notoriously difficult to develop and debug, so I got all of this working in https://github.com/btmills/release-please-test first. Feel free to reference that to see what the workflow is like. For example, btmills/release-please-test#15 is a release PR. I noted any manual configuration steps along the way and included them in the commit message and PR body for reference for future repositories. While I can't promise that this'll work on the first try, I'm hopeful that I ironed out all the kinks over in that test repository.

[btmills]

I didn't clean up the existing eslint-release dependency and package.json scripts in this PR. I'm happy to include that if you'd like, but I figured we'd like to try release-please first while retaining the option of releasing in Jenkins until we're sure we're ready to drop the Jenkins flow.

[bmish]

That seems reasonable.

[btmills]

This repository is currently configured to give workflows write access by default. Specifying only the precise $GITHUB_TOKEN permissions that release-please needs for this job reduces surface area and makes this workflow copy-pasteable to repositories that only grant read access by default.

[bmish]

This looks useful!

[nzakas]

It might be better to create the npm token secret at the organization level so it can be reused by all repos.

You can set the secret to only be available to this repo to start.

I just foresee a time where we need to update 20 tokens otherwise.

[nzakas]

By the way, we could also tweet out the release, as I do in my repos:
https://github.com/humanwhocodes/async-event-emitter/blob/e63c3b054c2fcdf422fc2f75ff1053801589d7f7/.github/workflows/release-please.yml#L33-L39

We already have our Twitter credentials as secrets to tweet out RFC updates, and at least so far, these automated tweets are still going out.

[btmills]

1. I moved NPM_TOKEN to the organization level and gave generator-eslint access.
2. I added the tweet action. That's the only part of this that I haven't tested on my test repository, but I'm hoping the rfcs repository example is sufficient to get this one right on the first try 🤞

[nzakas]

LGTM!