tslib discussion

Per @StrahilKazlachev request:

We need to settle how we want to handle TS helpers in codegen.

When compiling to ES5 -- or even ES6 (e.g. decorators) -- TS makes use of a few helper functions, for example `__extends` when using class inheritance in ES5, `__rest` when using rest properties, `__decorate` when using decorators.

By default, used helpers are emitted at the top of _each_ output file (only helpers used in that file, of course).
Aurelia is made of many files and it really adds up to a lot of redundant code. Even more so if we use `__awaiter` or `__generator`, which are large.

Fortunately, Typescript has two options to address this problem:

`--noEmitHelpers` does what it says. The generated code won't run unless your provide helpers in some way (likely a set of global variables).

`--importHelpers` imports the required helpers from `tslib` at the top of generated file. Module `tslib` is distributed and maintained by MS.

I think the `importHelpers` solution is the simplest, is maintained by MS (when there's a new helper or one needs changing), optimizes with bundlers like Webpack or Rollup and works along other TS code compiled with `importHelpers` (e.g. app code or other libs).

The main drawback that @EisenbergEffect doesn't like is that this means Aurelia would have an external dependency on `tslib`, whereas today it has none.

I would point out that all serious projects today use a bundler and that if someone doesn't want to use `tslib`, it's easy to map the name to another arbitrary module, even one distributed with Aurelia if we really want to go this route.

Start by reviewing the TypeScript code-generation setup and how ES5 or ES6 output currently handles helpers. Compare the mentioned noEmitHelpers and importHelpers options, including the proposed tslib dependency. Done means the project has a settled helper strategy and its impact on generated Aurelia output and dependencies is recorded.

Written by the indexing model from the issue text.