an ICode InvokeStyle can now answer whether it isSuper
new bytecode emitter, GenBCode, for now under a flag

GenBCode is a drop-in replacement for GenASM with several advantages:

  - faster: ICode isn't necessary anymore.
    Instead, the ASTs delivered by CleanUp (an expression language)
    are translated directly into a stack-language (ASM Tree nodes)

  - future-proofing for Java 8 (MethodHandles, invokedynamic).

  - documentation included, shared mutable state kept to a minimum,
    all contributing to making GenBCode more maintainable
    than its counterpart (its counterpart being GenICode + GenASM).

A few tests are modified in this commit, for reasons given below.

(1) files/neg/case-collision

    Just like GenASM, GenBCode also detects output classfiles
    differing only in case. However the error message differs
    from that of GenASM (collisions may be show in different order).
    Thus the original test now has a flags file containing -neo:GenASM
    and a new test (files/neg/case-collision2) has been added
    for GenBCode. The .check files in each case show expected output.

(2) files/pos/t5031_3

    Currently the test above doesn't work with GenBCode
    (try with -neo:GenBCode in the flags file)
    The root cause lies in the fix to
    https://issues.scala-lang.org/browse/SI-5031
    which weakened an assertion in GenASM
    (GenBCode keeps the original assertion).
    Actually that ticket mentions the fix is a "workaround"

(3) files/run/t7008-scala-defined

    This test also passes only under GenASM and not GenBCode,
    thus the flags file. GenASM turns a bling eye to:

      An AbstractTypeSymbol (SI-7122) has reached the bytecode emitter,
      for which no JVM-level internal name can be found:
      ScalaClassWithCheckedExceptions_1.E1

    The error message above (shown by GenBCode) highlights
    there's no ScalaClassWithCheckedExceptions_1.E1 class,
    thus shouldn't show up in the emitted bytecode
    (GenASM emits bytecode that mentions the inexistent class).
two bytecode tests atune with bytecode by GenASM
SI-5031 fixed in GenBCode

The GenASM-based fix for SI-5031 is 0527b2549bcada2fda2201daa630369b377d0877
[backport] relax time constraint in duration-tck.scala (for Windows VMs)
(cherry picked from commit 3e0fbc0193f0b6f58dc16dae3824677e9902dc7b)
Removed redundant `retypedMethod` in `Duplicators`

It was never used since its introduction in 3ee6b3653 by @dragos.

Review by @dragos or @axel22 or @paulp.
SI-7343 Fixed phase ordering in specialization

Specialization rewires class parents during info transformation, and
the new info then guides the tree changes. But if a symbol is created
during duplication, which runs after specialization, its info is not
visited and thus the corresponding tree is not specialized.

One manifestation is the following:
```
object Test {

  class Parent[@specialized(Int) T]

  def spec_method[@specialized(Int) T](t: T, expectedXSuper: String) = {
     class X extends Parent[T]()
     // even in the specialized variant, the local X class
     // doesn't extend Parent$mcI$sp, since its symbol has
     // been created after specialization and was not seen
     // by specialzation's info transformer.
     ...
  }
}
```
We can fix this by forcing duplication to take place before specialization.

Review by @dragos, @paulp or @axel22.
SI-6221 inference with Function1 subtypes.

There appears to be no upper bound on the number of places
we have to remove calls to typeSymbol and introduce calls to
baseType. This one was type inference for function parameter
types: worked when expected type was A => B, but not if there
was an implicit conversion from A => B to the expected type.
SI-7439 Avoid NPE in `isMonomorphicType` with stub symbols.

`originalInfo` can return null for stub symbols; deal with that
as we used to before a regression in 016bc3db.

After this change, we can once again delete A_1.class and still compile
code instantiating B_1. (A_1 is only referred to in a method signature
of B_1 which is not called from our code.)

	scala> new B_1
	warning: Class A_1 not found - continuing with a stub.
	res0: B_1 = B_1@5284b8f9

In practice, this situation arises when someone uses a third
party class that was compiled against other libraries not avaialable
on the current compilation classpath.
SI-7584 Fix typer regression with by-name parameter types

It regressed in fada1ef6b#L4L614. Partially reverting just
this change restores the correct behaviour:

```
-        if (sym.isStable && pre.isStable && !isByNameParamType(tree.tpe) &&
+        if (treeInfo.admitsTypeSelection(tree) &&
```

This patch embeds the check for by-name parameter types into
`TreeInfo.isStableIdentifier`. That code already checks for
`Symbol#isStable`, which exludes direct references to by-name
parameters. But the additional check is required to deal with
by-name parameters in function types, e.g `(=> Int) => Any`.

Open question: should we go further and embed this check in `isStable`?

Currently:

    final def isStable        = isTerm && !isMutable && !(hasFlag(BYNAMEPARAM)) && (!isMethod || hasStableFlag)

Such function types are an underspecified corner of the language,
albeit one that is pretty useful writing, for example, in the
signature of a lazy foldRight that can operate over infinite
structures:

    def foldRight[A, B](fa: F[A], z: => B)(f: (A, => B) => B): B

The next commit subjects them to a little testing.
SI-7584 Test and spurious warning fix for by-name closures

The enclosed test case exercises by-name closures, which were
the subject of the previous commit. In the process, a spurious
warning was eliminated.
SI-7582 ClassfileParser: populate privateWithin of Java module class

The `privateWithin` attribute of Java companion module classes was
correctly set under joint compilation (ie, when using JavaParser),
but not under separate compilation.

This commit remedies this. The test covers variety of Java symbols.
Merge pull request #2656 from gkossakowski/junit

Add JUnit support
Merge pull request #2646 from retronym/topic/duration-relax-2.10.x

[backport] relax time constraint in duration-tck.scala (for Windows VMs)
Merge pull request #2651 from VladUreche/issue/7343-2

SI-7343 Fixed phase ordering in specialization
SI-7582 Only inline accessible calls to package-private Java code

Two problems here.

The inliner was using `isPrivate` / `isProtected` to determine access.
The fallthrough considered things to be (bytecode) public. This is okay
in practice for Scala code, which never emits package private code.

Secondly, we must check accessibility of the called symbol *and* its
owner. This case is tested in `run/t7582b`.

This commit tightens the check for Java defined symbols: a) check the owner,
and b) don't assume that `! isPrivate` is accessible.
SI-7592 Replace s.t.n.u.TreeSet with s.c.m.TreeSet

This means
- migrating usages from the compiler-specific implementation to the
  one in the standard library
- removing the now unused compiler-specific implementation
SI-7571 Allow nesting of anonymous classes in value classes

5d9cde105e added deep prohibition of nested classes within
a value class. This has the undesirable side effect of
prohibiting partial functions literals in method bodies
of a value class.

The intention of that prohibition was to avoid problems
in code using Type Tests, such as:

    class C(val inner: A) extends AnyVal {
      class D
    }
    def foo(a: Any, other: C) = a match { case _ : other.D }

Here, the pattern usually checks that `a.$outer == other`.
But that is incongruent with the way that `other` is erased
to `A`.

However, not all nested classes could lead us into this trap.
This commit slightly relaxes the restriction to allow anonymous
classes, which can't appear in a type test.

The test shows that the translation generates working code.
Cleaning up method implementations in Future
    Optimizations:
    1) Avoiding isDefinedAt + apply and using applyOrElse to allow for optimizations later
    2) Reducing method sizes to be more JIT + inliner friendly
    3) Reusing core combinators to reuse inliner/JIT optimizations and be more code-cache friendly
Refactoring to the scala-concurrent-tck.scala
  - there were numerous logical issues with the former implementation
    - failed assertions may not fail the build
  - there was a lot of ceremony and noise