`dayjs` does not actually support Node.js ESM

Node.js has implemented native support for ESM in the real world, and the community is increasingly recommending the use of ESM instead of CommonJS (e.g: https://blog.sindresorhus.com/get-ready-for-esm-aa53530b3f77).

I noticed that `dayjs` actually publishes the `esm` directory, which contains the compiled product of the ESM syntax, see #1298. Although the `"module"` field of `package.json` was removed in #1314, the contents of `esm` are actually still available in the `` in browsers or in bundling tools such as `webpack`.

Unfortunately, Node.js [requires more than that](https://nodejs.org/api/esm.html#enabling) for ESM. Since this is a CommonJS package, the ESM files it provides must use the `.mjs` extension to be properly parsed by Node.js.

I can get a few ways to solve this problem, but perhaps none of them are very good:
- The easiest way to make it work is to replace the `.js` extension with `.mjs` in `build/esm.js`, but obviously this will cause breaking changes for scenarios that already use ESM files.
- We can also publish a new `node-esm` directory for `.mjs` files for Node.js. But `node-esm` is not a good name for forward compatibility reasons.
- Further, as described in #1314, continue to push the implementation of the `dayjs-esm` package, just like `lodash-es`.
- If we take this approach, we also no longer need to use the `.mjs` extension. Just keep using `.js`.

I'm not sure if you have plans for this in terms of Node.js ESM, but I think that this is the way to go.

Start by reading build/esm.js, package.json, and the published esm directory, then compare their output with Node.js native ESM requirements. Decide which packaging approach preserves existing browser and bundler use while enabling Node.js ESM; done means the supported package can be imported by Node.js without breaking current ESM consumers.

Written by the indexing model from the issue text.