[dart2wasm] Better infrastructure/tooling to debug where binary size is coming from

[mkustermann]

Currently we have very little insight on where code size for dart2wasm compiled apps are coming from, why something wasn't tree shaken etc.

The VM's AOT compiler has for example --trace-precompiler-to that allows dumping information on why certain functions/fields/... were not tree shaken. The resulting information is dumped into a json that can be analyzed.

It would be nice to have tooling one can use to query: How much size comes from async functions, size per dart function/class/file/package ...

What makes this more complicated is that the actual size is only relevant after binaryen has run - our unoptimizing dart2wasm compiler may emit lots of code that's shranken by binaryen.

[mkustermann]

I've started to do a prototype on this based on information we have in source maps which is updated by binaryen and therefore somewhat accurate.

[kevmoo]

I'd LOVE to have this.

It'd also be super useful to compare with coverage information to understand, for "un-hit" code, if there are library/framework changes we could make to reduce size!