Because the source code is written in ESM syntax and we cannot use the
`esm` package to make `require()` ESM compatible, since that package
does not support legacy versions of Node.js.

Also in our usage tests in CI, we need to mimck the npm packaging
behaviour where building is involved.

Although we'll now end up with only `mustache.js` in the git repo,
being written in ESM syntax, the npm package will still be as before:

- `mustache.js`: UMD, meaning CommonJS, AMD or global scope
- `mustache.mjs`: ESM

No need for X amount of different Node.js version to all run the linting
as part of their CI rutine. Easier to just run that once, completely
separate from the unit tests.

Primarily to group similar kinds of "usage" tests together, which are
all either verifying the use of mustache.js from consuming party' point
of view.

Now that Node.js 8 is end-of-life / no longer maintained, we might as
well treat it as a legacy Node.js version too.

..blooper introduced in the latest commit where submodules were to be
pulled to make sure mustache spec tests were included in test runs.

Our test suite already has support for running mustache specs,
but looks like we've forgotten about them in CI for many years now.

Because it seems the standard library for v0.21 that was used in the
usage tests before has been removed, it returns 404 now..

With the introduction of a build step, where we take the source in .mjs
and build it into .js for non-ES Module systems, it's very important
that we remember to keep those two in sync.

That's what the CI job created in these changes ensure;

1. Run the build script
2. See if there are any pending git changes as a result

As long as there are no pending git changes, we're all fine and dandy,
or else we need to run the `npm run build` and commit the changes.

To ensure the ES module and source exposed by this package is compatible
with Deno going forward.

Added benefit is we get some sanity checks of the source code for free
due to Deno's built-in TypeScript compiler getting angry if it sees
things that does not make sense, in terms of missing function arguments
and so on.

This is a precursor to introducing a build step that will change what
we expose from this package. Better off writing some tests to verify
existing projects with different module systems continue to work as
expected.

This is a precursor to introducing a build step that will change what
we expose from this package. Better off writing some tests to verify
existing projects with different module systems continue to work as
expected.

Primarily because it's getting to be a pain in the backside to always
consider pre Node.js 6 when wanting to use up-to-date dependencies.

When initially creating the GitHub Actions
workflow, it was obviously forgotten to make
it also run on pull requests, not only when
changes are pushed to branches in the
original repository (not a fork).