Improve inlining "heavyweight" mode by excluding call sites

[MaxGraey]

This PR remove lightweight property from FunctionInfo and use two booleans hasCalls and hasLoops instead of it. It allows exclude functions with call sites. Otherwise potentially recursive functions will explode compilation time or/and code size.

Also rename allowHeavyweight to allowFunctionsWithLoops.

[kripken]

More generally, at the high level I think we need to decide on what the API should be here. And have specific reasons for why we think calls vs loops etc. matter.

As I said earlier, the existing logic was basically motivated by the fact that code without loops and without calls will run exactly once at most and as no surprising additional work happening. So it's fairly straightforward to estimate how much work will be done there. And specifically, to see that the work is likely very small, hence the inlining can help by removing call overhead to there.

So starting with a clear design about what you want to achieve here would be a good starting point I think @MaxGraey

[dcodeIO]

As far as I understood the motivation for this change was that we are currently seeing Binaryen hanging forever when we try to compile the AssemblyScript compiler with allowHeavyweight=true, and Max figured that this is from recursively inlining heavyweight calls. As such, loops are fine, but calls are not. May well be that there is a better solution than just disabling calls, though.

[MaxGraey]

May well be that there is a better solution than just disabling calls, though.

inlining functions with calls should be avoided in any case, we could only enable / disable funcs with loops so current approach I think is fine)

[kripken]

I see, thanks @MaxGraey and @dcodeIO

Yes, the infinite recursion issue with calls is a good reason to change this API. lgtm with some comment changes.