Provide data about necessity of core-js modules for target engines.

[zloirock]

caniuse, mdn and compat-table are good educational resources but are bad data sources for providing only required polyfills for target engines. Only compat-table from this list contains at least some useful data and at this moment it's used in babel-preset-env, however, it's limited:

• compat-table contains data only about ECMAScript features and proposals, not about web platform features. So, for example, babel-preset-env adds all web platform features from core-js even in environments where they are supported.
• core-js contains also fixes for broken implementations, but compat-table does not contain any information even about serious bugs in engines (for example, Array#reverse broken in Safari 12).
• compat-table contains only some basic and naive tests, they do not show that features work even basically as should. For example, old Safari have broken iterators without .next method, but compat-table shows them as supported because just check that typeof of methods which should return iterators is function. Some features like typed arrays are almost completely not covered.
• compat-table is not designed for providing data for tools, some of the rest compat-table maintainers against of maintaining this functionality.

So let's provide data about the necessity of core-js modules for target engines.

This PR contains:

• core-js-compat package with data about the necessity of core-js modules and API for getting a list of required core-js modules by browserslist query.
• Test case based on core-js feature detection - we can't add the full core-js test case to runtime, but those tests overlap the rest - for each core-js module.
• Extension of core-js-builder package for allowing targets option with browserslist query.

Feel free to test and provide data / mapping for missed engines.

[nicolo-ribaudo]

Test case based on core-js feature detection - we can't add the full core-js test case to runtime, but those tests overlap the rest - for each core-js module.

If we mock core-js/internals/export (either by replacing it with webpack or using a global/env variable), wouldn't it be possible to reuse the same checks that core-js does at runtime?
I don't know if it is actually feasible.

[zloirock]

@nicolo-ribaudo I was thinking about something like that, but it looks problematically.

[existentialism]

@zloirock awesome stuff, really excited about this!