chore: decrease UI build size

[e00dan]

Changes:

• Decrease UI bundle.js size from: 8.37 MB to 3.2 MB
• Enable GZIP in UI docker-compose (which gets it further down to around 1 MB)
• Add separate tsconfig.build.shakeable.json files which use es2015 modules, so tree-shaking for tools like webpack is possible (commonjs won't work)
• Generate ABI-only contract wrappers in user-registry, asset-registry, origin, market
• Export full contract JSON files separately from other logic

Issues:

• ts-loader does not exit after UI build - Fix SolutionBuilder watches TypeStrong/ts-loader#1003

Future ideas:

• We could leverage Node.js 12 experimental modules and this way we possibly wouldn't need commonjs at all

[kosecki123]

So this creates alternative es modules based pipeline which them can enable better UI optimizations.

What if we would switch to es modules by default? Besides UI we have few packages which are executables, we can configure the run so they use esm for instance or we configure bundlers for those projects.

[e00dan]

Trying to switch to es6 gives following scenario, for example, utils-demo (commonjs) depends on market (es6), this results: utils-demo will crash with error: unexpected identifier import.

Utils-demo would have to compile differently modules it depends on, which, would also create 2 alternative build pipelines.

Ts-node or ts compiler in utils-demo doesn't compile dependencies, so import keywords in dependencies stay as they are, and when utils-demo try to use that dependencies JS code, there's a crash.

Switching to es modules where most of our packages are meant to run by node.js could make the pipeline more complicated, because it basically means that we break compatibility with it, unless we would be on higher version of node.js, which I believe is impossible because of our web3 dependency.

That said, I'm keen to experiment more and will keep thinking on how to improve our flow.