This updates `eslint-release` to have separate commands for generating a release locally, and publishing info about the release to various locations (npm, git, GitHub releases). In addition to making it easier to deal with failures (since we won't end up in a half-published state), this will also make it possible to provide a 2FA code for publishing that will still be valid when it's actually time to publish.

To make future changes easier, this also removes some functionality that is no longer used (e.g. the distinction between CI and non-CI releases, and the ability to publish the changelog to GitHub changelog separately from the rest of the release)

Migration for existing projects:

* Projects that run the `eslint-release` command should run `eslint-generate-release` followed by `eslint-publish-release`.
* Projects that run the `eslint-prerelease <releaseId>` command should run `eslint-generate-prerelease <releaseId>` followed by `eslint-publish-release`.
* Projects that use `ReleaseOps.release(releaseInfo)` should run `ReleaseOps.generateRelease(releaseInfo)` followed by `ReleaseOps.publishRelease()`.

When publishing, an `NPM_OTP` environment variable can optionally be used to authenticate the publish.

The npm publish is generally more likely to fail than the git push (e.g. as a result of making a typo in a OTP). This updates the script to try publishing to npm first, to avoid creating an inconsistent state if the npm publish fails.

This should make it slightly easier to figure out what's going on if any issues need to be debugged.