Browser-based variant for direct use

**Is your feature request related to a problem? Please describe.**

We're working on a graphical editor as part of the larger web-based development environment [lively4](https://lively-kernel.org/lively4/lively4-core/start.html) (self-supporting, live programming, wiki-like):


We want to add type support via TypeScript to data-related edges in the graph for more efficient input and clearer visuals (e.g color ports and edges by type, instead of our steelblue placeholder).

While working with the TypeScript Compiler API would be manageable, ts-morph seems like a much better fit for non-file-based code such as ours.

Unfortunately, ts-morph seems not to be easily available to browser-based environments. As an example `import {Project} from 'https://unpkg.com/ts-morph@16.0.0/dist/ts-morph.js'` results in the following error:

```
Error: SystemJS error: could not load https://lively-kernel.org/lively4/aexpr/@ts-morph/common
Instantiating https://lively-kernel.org/lively4/lively4-core/@ts-morph/common
Loading https://unpkg.com/ts-morph@16.0.0/dist/ts-morph.js
Loading workspace:9438ce51-a88e-4d03-b463-36579d41c73d/lively-kernel.org/lively4/lively4-core/unnamed_module_477b3665_e486_4631_b5ac_afeb81621f56
```

potentially, because _@ts-morph/common_ and _code-block-writer_ are declared as external dependencies with a `"bundleDependencies": false`.

**Describe the solution you'd like**

We like to use ts-morph via a simple drop-in, e.g. via a cdn or self-hosted. For this a simple bundled version of ts-morph would suffice (EcmaScript module format). Ideally, it would be non-minified to enable proper debugging and monkey patching to some degree.

As ts-morph likes its users to use their custom `ts` export instead of the _typescript_ one, maybe typescript should be included in the bundle. I'm unsure here.

This issue seems to align with the general desire of using ts-morph in browsers (#171, #361, #364). To support this desire, ts-morph should be easily available to developers, instead of making all its users having to deal with the accidental complexity of JavaScript's modern eco system. For many developers, this might increase the appeal to try and toy around with ts-morph.

**Describe alternatives you've considered**

One alternative for us would be to fallback to the drop-in variant of typescript directly (e.g. _https://cdnjs.cloudflare.com/ajax/libs/typescript/4.8.4/typescript.js_).
However, this would entail writing our own wrapper that would mostly replicate the same/similar functionality ts-morph already provides.
Instead, we would like to use your library directly.