Add 'tslib.umd.js' to avoid global pollution

[rbuckton]

This adds a tslib.cjs.js file as the package main to reduce the impact of global variable pollution, as well as some additional variants. Also, in an effort to avoid redundancy between each variant, this adds a script to generate all files from a single source.

This also leaves tslib.js as is as it still has a use case to support both --importHelpers for modules and scripts (which depend on the helpers being available as globals).

Fixes: #32

[rbuckton]

This also paves the way for the possibility of supporting #33 as the generator script can be easily modified to emit each helper into its own file (current progress can be seen in https://github.com/Microsoft/tslib/tree/oneHelperPerFile).

[rbuckton]

I've updated this to support multiple variants:

• tslib.js - A bundle of all helpers that supports both CommonJS and AMD modules as well as adds global (for use with <script></script> tags).
• tslib.umd.js - A bundle of all helpers that supports both CommonJS and AMD modules, but does not add global variables.
• tslib.cjs.js - A bundle of all helpers that supports only CommonJS (this is the default variant used as "main" in package.json).
• tslib.amd.js - A bundle of all helpers that supports only AMD.
• tslib.es6.js - A bundle of all helpers that supports ECMAScript module syntax.
• tslib.global.js - A bundle of all helpers that only adds globals (for use with <script></script> tags).

[rbuckton]

@DanielRosenwasser If we end up taking this, should I also emit a copy of tslib.es6.js as tslib.mjs?

[slaneyrw]

Any action on this, global window pollution is a real problem

[Clashsoft]

Any news on this?