These changes adds an `exports` field to package.json with the main
goal of allowing the root/main export to be our ESM syntax version of
the package, as opposed to the UMD/CommonJS version.

This will make it easier for using projects written with ESM to use
mustache.js out of the box, without having to figure out that they'd
have to `import mustache/mustache.mjs` to get the ESM version.

It is also assumed to be beneficial for tools like http://skypack.dev
to choose the correct ESM version when appropriate.

Refs https://nodejs.org/api/packages.html#packages_package_entry_points

As seen from the test run log:

```
$ deno test --allow-net=deno.land test/module-systems/deno-test.ts

Compile file:///home/runner/work/mustache.js/mustache.js/.deno.test.ts
Download deno.land/std@v0.51.0/testing/asserts.ts
Warning std versions prefixed with 'v' were deprecated recently. Please change your import to deno.land/std@0.51.0/testing/asserts.ts (at deno.land/std@v0.51.0/testing/asserts.ts)
error: Uncaught Error: Import 'deno.land/std@v0.51.0/testing/asserts.ts' failed: 404 Not Found
    at unwrapResponse ($deno$/ops/dispatch_json.ts:43:11)
    at Object.sendAsync ($deno$/ops/dispatch_json.ts:98:10)
    at async processImports ($deno$/compiler.ts:736:23)
```

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

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.

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.