SI-8062 Fix inliner cycle with recursion, separate compilation

ICodeReaders, which decompiles JVM bytecode to ICode, was not
setting the `recursive` attribute of `IMethod`. This meant that
the inliner got into a cycle, repeatedly inlining the recursive
call.

The method name `filter` was needed to trigger this as the inliner
heuristically treats that as a more attractive inlining candidate,
based on `isMonadicMethod`.

This commit:

  - refactors the checking / setting of `virtual`
  - adds this to ICodeReaders
  - tests the case involving `invokevirtual`

I'm not sure how to setup a test that fails without the other changes
to `ICodeReader` (for invokestatic and invokespecial).
Revert "SI-6426, importable _."

This reverts commit d2316df920ffa4804fe51e8f8780240c46efa982.

We can't make `_` an illegal identifier -- it's legal in Java,
so we must be able to name these Java underscores.
Merge pull request #3253 from retronym/ticket/8062

 Fix inliner cycle with recursion, separate compilation
Merge pull request #3261 from adriaanm/ticket-6426

Revert ", importable _."
Partially revert f8d8f7d08d.

Need `${dist.dir}/lib/scala-partest.jar` for maven publish.

We still don't want to distribute it in the distribution,
but will have to remove it in release script, as 2.10.x's
build hasn't been refactoreded like master's, and I'm not backporting it.
Report error on code size overflow, log method name.

We used to silently skip class files that would exceed the JVM's size limits.
While rare, this should still be an error.

While I was at it, also included the name of the offending method.
Merge pull request #3268 from adriaanm/support-3021

Report error on code size overflow, log method name.
GenBCode version of "Updating Position call sites" commit

7d62df035cd4393c73e7530e1cad1130e79d90c6 modifies GenASM, we follow suite here.
GenBCode version of "not eliminate loadmodule on static methods."

f27f2d80d759130597b652d6cc9d789f8c472e5a modifies GenASM, we follow suite here,
making test/files/run/static-module-method.scala pass under GenBCode.
there's a reason for this code in GenBCode

aced32d05c97651534f468bc9a475ea5f6ae75b8 removed unused code,
along with code that populates a cache with entries needed
in some program runs. I'm re-adding the latter.
removing dead code in BCodeSyncAndTry
overzealous assert in GenBCode

The assert in question was aimed at ruling out
gotos (ie "jumping-applys") in actual argument position
of a jumping-apply.

But the assert in question went overboard
to also rule out a LabelDef in actual argument position.

This commit removes the assert in question altogether.

The unwanted behaviors, and only those, are rule out by
the test added in this commit and the existing tests for SI-6089.

See also https://issues.scala-lang.org/browse/SI-7749
removing defensive code made obsolete by existing fix to SI-5604

SI-5604 was fixed in commit e6f10b07d44f0ddde26246b4a41527a84eede81c
overzealous assert in BCodeBodyBuilder rejected throw null
Dotless type application for infix operators.

When you have an aesthetic expresion like

  def f(xs: Iterator[Int]) = (
    xs takeWhile (_ < 1000)
             map (_ * -1)
          filter (_ % 2 == 0)
         flatMap (x => List(x, x))
    reduceOption (_ + _)
           maxBy (_.toString)
  )

And then for whatever reason you have to perform explicit
type application in the midst of that expression, it's
aggravating in the extreme that it has (had) to be rewritten
in its entirety to accommodate that change.

So now you can perform type application in the middle of it.

For reasons not entirely clear to me postfix operators are
excluded. The discussion as well as the approval for the infix
variation of it can be found at:
  https://groups.google.com/forum/#!msg/scala-language/eJl1wnkEz9M/hR984-lqC5EJ
Test demonstrating SI-8085

* The presentation compiler sourcepath is now correctly set-up.
* Amazingly enough (for me at least), the outer import in the
  package object seem to be responsible of the faulty behavior.
  In fact, if you move the import clause *inside* the package object,
  the test succeed!
  The test's output does provide the correct hint of this:

```
% diff /Users/mirco/Projects/ide/scala/test/files/presentation/t8085-presentation.log /Users/mirco/Projects/ide/scala/test/files/presentation/t8085.check
@@ -1,3 +1,2 @@
 reload: NodeScalaSuite.scala
-prefixes differ: <empty>.nodescala,nodescala
-value always is not a member of object scala.concurrent.Future
+Test OK
```

Notice the ``-prefixes differ: <empty>.nodescala,nodescala``. And compare
it with the output when the import clause is placed inside the package
object:

```
% diff /Users/mirco/Projects/ide/scala/test/files/presentation/t8085-presentation.log /Users/mirco/Projects/ide/scala/test/files/presentation/t8085.check
@@ -1,4 +1,2 @@
 reload: NodeScalaSuite.scala
-reload: NodeScalaSuite.scala
-open package module: package object nodescala
 Test OK
```

Notice now the ``-open package module: package object nodescala``!
SI-8085 Fix BrowserTraverser for package objects

A source file like:

    import foo.bar
    package object baz

Is parsed into:

    package <empty> {
       import foo.bar
       package baz {
          object `package`
       }
    }

A special case in Namers compensates by adjusting the owner of
`baz` to be `<root>`, rather than `<empty>`.

This wasn't being accounted for in `BrowserTraverser`, which
underpins `-sourcepath`, and allows the presentation compiler to
load top level symbols from sources outside those passes as
the list of sources to compile.

This bug did not appear in sources like:

    package p1
    package object p2 { ... }

... because the parser does not wrap this in the `package <empty> {}`

This goes some way to explaining why it has gone unnoticed for
so long.
Merge pull request #3282 from retronym/ticket/8085

 Fix BrowserTraverser for package objects
SI-8100 - prevent possible SOE during Stream#flatten.

This commit changes stream flatten to avoid allocating a
stack frame for every stream item. Previously, flattening
a stream whose elements are mostly empty would result in
a StackOverflowException.

This commit also adds a test demonstrating the problem.
[nomaster] codifies the state of the art wrt SI-8104

As it was discovered in SI-8104, whiteboxity doesn’t apply equally to
type parameters and type members of materialized type classes.

During implicit search and subsequent type inference, whitebox type parameters
are consistently erased to wildcards, whereas whitebox type members sometimes
remain as is and get in the way of signature conformance checks.

Unfortunately, 2.10.x can’t make use of type parameter whiteboxity, because
it requires fundep materializers that were only merged into 2.11:
https://github.com/scala/scala/pull/2499, and therefore Si-8104 seems to be
a hard blocker for 2.10.x at the moment. Stay tuned for updates.