Add end-to-end test suite

[mcous]

Overview

This PR adds a Verdaccio-based end-to-end test suite to CI, which spins up an NPM registry on localhost in the runner and tests that:

• The CLI is able to publish a package
• The action is able to publish a package
• The CLI will not publish a package if the version is already published
• The action will not publish a package if the version is already published

These tests run through a lot of the code, which means we get pretty decent bang for our buck, and we can defer a lot of smaller behaviors to isolated unit tests. Most importantly, they only work if our registry auth logic is working, which is probably the most mission-critical logic in the module.

This PR should merge before anything else lands. I've added the E2E status check as a requirement for any PR merging into the main branch.

Background

The existing test suite of this action can't be used for actual regression protection, because it mocks out the npm binary, in the classical sense. Each test forms a set of expected calls to npm and return values for each of those calls. If any of those calls doesn't happen, or happens in a different manner than specified, the test fails.

From a development standpoint, this has the following downsides:

• The tests don't tell us if the module actually works
  • Instead, they tell us that the module calls npm in the way we think npm is supposed to be called
  • We could be wrong about how we're supposed to call npm!
• If we change how we call npm, the tests will automatically fail, even if the changes are correct
  • That means we can't refactor how we call npm without also refactoring the tests
  • Instead of being a stable platform that we develop against, the tests are now just another thing we have to change where we could introduce bugs

Changes

• Add E2E job to CI, powered by Docker and a few small bash scripts in ./e2e
• Various CI improvements
  • Run CI weekly rather than monthly
  • Upgrade coveralls action
  • Move common Node.js setup to little composite action
  • Separate linting job from matrixed test job so we don't get duplicate linting warnings
  • Separate build job from publish jobs
  • Make sure E2E tests run against the code that will actually be published (or is committed, in the case of the action) rather than building fresh every time