Now anyone can define meteorInstall.fetch however they see fit, and the
install.js implementation will handle everything else.
This separation of concerns leads to significantly less code, too.
As proposed here: https://github.com/rollup/rollup/wiki/pkg.module
By supporting ECMAScript module entry points for npm packages in Meteor
1.5, we will be well-positioned to do more effective import/export-based
tree shaking in future versions of Meteor.
We can't do the same thing on the server because we can't change how
native Node resolves package entry points based on the "main" field of the
package.json module.
On the other hand, all npm packages have to work in Node using the "main"
field, and client bundles stand to benefit the most from tree shaking, so
this client/server difference should not be problematic.
Note that the "jsnext:main" property is also supported as a legacy synonym
for "module".
