Migrate to named exports and provide node esm support

[TrySound]

In this diff I added new entry point to compile es modules with named
exports to solve this problem (#240).

It's a breaking change so we can drop legacy node support (newer
versions of rollup and many other tools requires this) and add native
node es modules support.

[jordanbtucker]

Thank you for this PR, but I think it adds too much complexity compared to #243. Instead of one entry point (lib/index.js) there are now two (lib/index.js and lib/esm.js) as well as dist/index.mjs which is redundant. Removing dist/index.mjs is a breaking change, so you end up with two ESM compatible entry points that do the same thing, one used by Node.js and the other used by webpack.

There is also a module field and an exports field that each point to different entry points, which confuses things further.

You've also removed the browser field from package.json, which ensures that certain polyfills are included. And lib/esm.js cannot be used by browsers because both parse.js and stringify.js require util.js.

[TrySound]

esm.js is used only for building proper exports in dist/index.mjs because generating exports from commonjs is not reliable and may change with rollup upgrade. I do not suggest to remove dist/index.mjs.

"module" is bundler specific field. "exports" is node specific way to support es modules natively. Probably only webpack 5 support both them yet.
https://nodejs.org/api/packages.html#packages_conditional_exports

Here's example
https://unpkg.com/browse/nanoid@3.1.12/package.json

"browser" field should not just point to umd. Bundlers prefer "browser" field over over "module" when specified as a string. This makes "module" field useless in this case. See the correct use case for "browser" field https://github.com/visgl/react-map-gl/blob/master/package.json#L17-L25