Separate the knowledge query getMethodBody() from resolve calls.

The three existing knowledge queries staticCall, dynamicCall and
traitImplCall are not invalidated anymore if the *body* (the
`originalDef`) of a MethodImpl changes. They are invalidated only
for added methods, removed methods, and when a public "attribute"
of a method changes.

Attributes are the `inlineable` and `isTraitImplForwarder` flags.
They are exposed clearly in the MethodID interface, which is what
is returned from the three queries above.

A MethodID does not give access to its body. To do that, another,
separate knowledge query getMethodBody() is provided.

This separation follows what we described in the paper. It makes
sure we do not break our own assumptions by encoding in the type
system that MethodID only gives access to the flags that are
examined for the three xxCalls queries; and not to the body
itself.

It has at least one direct advantage in terms of accuracy of
detecting what to reoptimize: if only the body of an inlineable
method changes (but it remains inlineable and keeps the value of
its isTraitImplForwarder flag), then call sites that could call
that method with a dynamicCall, but cannot actually inline it
because there are multiple targets, need not be reoptimized.
This is especially important for the FunctionN.apply() case,
because all anonymous functions that are compiled as classes have
their apply method marked with @inline.

There is another potential advantage for the future: it makes it
possible, and sound, to decide to inline a method even if it does
not have the inlineable flag on.
Merge pull request #1100 from sjrd/separate-query-getmethodbody

Separate the knowledge query getMethodBody() from resolve calls.
Fix #1101: Do not unbox results of raw JS calls in statement position.

This aligns with the semantics of generics.
Fix #1082: Export modules and classes to fully qualified name
Merge pull request #1102 from sjrd/no-unbox-in-stat-pos

Fix #1101: Do not unbox results of raw JS calls in statement position.
Merge pull request #1093 from gzm0/fully-qualified-export

Fix #1082: Export modules and classes to fully qualified name
Aggressively inline methods when arguments are "likely" optimizable.

If at least one of the receiver and arguments to a method call
is "likely optimizable", then we force inlining of the method,
even if it is not inlineable.

An argument is likely optimizable if it is a LocalDef for a
tentative anon fun replacement, or for an inlined class instance
(i.e., a record var ref).

At the same time, we removed ad-hoc @inline's on methods, because
they were targeted at the use case now better covered by this
improvement.

Together, these changes perform less inlinings that serve no
purpose, and more inlinings that do bring improvements.
Merge pull request #1103 from sjrd/aggressive-inlining

Aggressively inline methods when arguments are "likely" optimizable.