Add support for ECMAModules import

[budnix]

The PR improves how the distributed files are published to the NPM. From now on, the module should support not only Node require syntax but import syntax as well. The changes forced a dependency upgrade.

The dist files are tested using different bundlers and environments. The following bundlers are tested:

• Rollup 1 and 2;
• Webpack 2, 3, 4, and 5;
• Parcel;
• NodeJS 6 and 15 using native require and import syntax.
• The UMD files (including minified) are tested on the most popular browser. I've tested on IE9-11 and haven't seen any problems.

[mrpiotr-dev]

Seems to work as expected. By the way, I've noticed a few tiny things:

1. lockfile version is bumped to V2 - maybe we should add npm's min version in engines entry in package.json?

npm WARN read-shrinkwrap This version of npm is compatible with lockfileVersion@1, but package-lock.json was generated for lockfileVersion@2.

2. On Win10 I had a problem with EOL - I guess .gitattributes file should solve the problem.

3. On Win10/macOS10.15, npm 7.3.0, node15.4.0 I got 4 failure in tests - all of them are related to floated numbers precision (I guess it's @handsontable/formulajs issue)

4. Should we adjust @handsontable/formulajs package? At the moment we import dynamically required files from @handsontable/formulajs/index.js (it's a main entry point for that package). It is the "dual package hazard" we try to avoid, isn't it?

But I think the above list is not required to finish this PR - it's up to you 🙂
Well done @budnix!

[budnix]

Thanks for the review :)

1. lockfile version is bumped to V2 - maybe we should add npm's min version in engines entry in package.json?

npm WARN read-shrinkwrap This version of npm is compatible with lockfileVersion@1, but package-lock.json was generated for lockfileVersion@2.

I recreated the file (771b36b) to be compatible with the NodeJS version used within the project (v10).

1. On Win10 I had a problem with EOL - I guess .gitattributes file should solve the problem.

I've added the file in this commit 771b36b.

2. On Win10/macOS10.15, npm 7.3.0, node15.4.0 I got 4 failure in tests - all of them are related to floated numbers precision (I guess it's @handsontable/formulajs issue)

Yes, depends on used the NodeJS version the precision differs. So far I have added to the contributing.md file a point that describes the NodeJS version requirement.

3. Should we adjust @handsontable/formulajs package? At the moment we import dynamically required files from @handsontable/formulajs/index.js (it's a main entry point for that package). It is the "dual package hazard" we try to avoid, isn't it?

The @handsontable/formulajs package offers only the CommonJS syntax so I don't think that there is a possibility for "dual package hazard".

[mrpiotr-dev]

LGTM 👍