Use Binaryen's directed inlining

[dcodeIO]

This replaces our custom inlining with what's proposed in this Binaryen PR. Uses a custom Binaryen build for that purpose currently and probably needs some additional work, but pinning it here already so we can have a look how that'd turn out.

[MaxGraey]

@dcodeIO
https://github.com/AssemblyScript/assemblyscript/blob/directed-inlining/src/resolver.ts#L791
https://github.com/AssemblyScript/assemblyscript/blob/directed-inlining/src/resolver.ts#L814

[MaxGraey]

Also need fix warnings like WARNING AS206: Compiling constant with non-constant initializer as mutable. somehow

[dcodeIO]

Hmm, that might turn out to be quite a problem. Previously, we could just precompute inlined calls, which we can't anymore because inlining is performed on finalization. That's actually a good reason to keep our own inlining, unless we could BinaryenCallInline directly as noted in the other PR, which would require some significant changes to how Binaryen's code generation works... :(

[MaxGraey]

binaryen has method which could check cost for function and get possibility for inlining it and also side effect checking. So what if just check if it return true compiler try evaluate expression/function and try retrieve constant as result?

[dcodeIO]

Yeah, good idea. Precompute would essentially have to evaluate called function bodies for this. Not just constant returns, though, but also calls to other functions that might again be inlined etc. (probably everything)

[MaxGraey]

Hmm. It seems make sense keep some own inline stuff specially for class field's initialization

[dcodeIO]

Plus, seems the build breaks because of webpack running out of memory (or something, again). I didn't see that coming.

[MaxGraey]

Try to update webpack to latest. It may be this already fixed bug: webpack/webpack#8639

[MaxGraey]

It seems same issue:
webpack/webpack#6389

[MaxGraey]

Need to try node --max_old_space_size=2048 ./node_modules/webpack/ ... or try disable source maps for uglify plug-in

cc @xtuc

[dcodeIO]

Closing in favor of #463