Presentation compiler hyperlinking on context bounds test

Added test to the presentation compiler regression suite to exercise
hyperlinking on context bounds.
SI-4287 Added test demonstrating hyperlinking to constructor's argument

This test was inspired by `test/files/run/t5603`, whose output (.check file)
will need to be updated in the upcoming commit that fixes SI-4287, because
the positions associated to the tree have slightly changed.

The additional test should demonstrate that the change in positions isn't
relevant, and it doesn't affect functionality. In fact, hyperlinking to a
constructor's argument work as expected before and after fixing SI-4287.
SI-4827 Test to demonstrate wrong position of constructor default arg

As demonstrated by the attached test, hyperlinking on constructor's
default arg doesn't work (the returned tree is the parameter tree,
i.e., `f`, which is of course wrong).

Printing the tree reveals the issue:

``
[[syntax trees at end of                     typer]] // Foo.scala
[0:63]package [0:0]<empty> {
  [0:37]class Baz extends [9:37][39]scala.AnyRef {
    [10:31]<paramaccessor> private[this] val f: [14]Int = _;
    [14]<stable> <accessor> <paramaccessor> def f: [14]Int = [14][14]Baz.this.f;
    [39]def <init>([14]f: [17]<type: [17]scala.Int> = [30]B.a): [9]Baz = [39]{
      [39][39][39]Baz.super.<init>();
      [9]()
    }
  };

  [6]<synthetic> object Baz extends [6][6]AnyRef {
    [6]def <init>(): [9]Baz.type = [6]{
      [6][6][6]Baz.super.<init>();
      [9]()
    };
    [14]<synthetic> def <init>$default$1: [14]Int = [30]B.a
  };
  [39:63]object B extends [48:63][63]scala.AnyRef {
    [63]def <init>(): [48]B.type = [63]{
      [63][63][63]B.super.<init>();
      [48]()
    };
    [52:61]private[this] val a: [56]Int = [60:61]2;
    [56]<stable> <accessor> def a: [56]Int = [56][56]B.this.a
  }
}
``

In short, the default argument in `<init>` (the constructor) has an
offset position, while we would expect it to have a range position.
Therefore, when locating a tree for any position between (start=) 10
and (end=) 31, the paramaccessor tree `f` is returned.

The next commit will correct the problem.
SI-7492 Make scala.runtime.MethodCache private[scala]

These are internal implementation details which shouldn't be exposed
to users (and might go away when support for invokedynamic is added).
Improved testing framework for sets and maps.

Switched to JUnit testing framework for sets and maps.  They now test
broadly against each other for consistency.  Tests for mutable.AnyRefMap
and mutable.LongMap are folded in here (originals removed).  There is still
lots of redundancy with other tests that has not been removed.

This framework is also designed to enable more robust testing of changes to
implementations of sets and maps; although it's still quite possible to get
a broken implementation through, these tests should make it harder to get
the fundamentals wrong.
macroExpandApply => macroExpand

Back then, when we needed separate macro expanders for both applications
and unapplications, it made sense to have two different methods that
do macro expansions.

However, after @paulp’s upgrade of the pattern matching engine, we no longer
need a dedicated expander for unapply, so I’m removing it and renaming
`macroExpandApply` to just `macroExpand`.
gives a more specific signature to `computeMacroDefType`

I guess having `computeMacroDefType` is the remnant from the times when
we considered an immediate possibility of having non-defdef macros, for
instance type macros, which would be TypeDefs.

These happy early days are gone, type macros have been long buried,
and the perspectives of extensions to the existing def macro scheme are
unclear. Therefore let’s have maximally precise types right away and then
think of generalization later on, once/if we get there.
removes some copy/paste from AnalyzerPlugins

Abstracts away the foldLeft-based iteration pattern behind CumulativeOp[T].
In order to avoid performance regressions, `pluginsPt` and `pluginsTyped`
are special-cased for empty lists of analyzer plugins.
unprivates important helpers in Macros.scala

This is the first commit in a pull request that makes macro engine
extensible by analyzer plugins.

Such helpers as `macroArgs` and `macroExpandWithRuntime` have proven
to be indispensable in macro paradise, so it’ll be important to have
them available to macro plugins.
hooks for typecheck and expansion of macro defs

Creates MacroPlugin, a sister interface of AnalyzerPlugin in the namer/typer
extensibility interface.

Exposes `pluginsTypedMacroBody`, `pluginsMacroExpand`, `pluginsMacroArgs`
and `pluginsMacroRuntime` in the macro plugin interface. This will
make it easy to prototype changes to the macro engine without disturbing scala/scala.
humane reporting of macro impl binding version errors

Macro defs are linked to macro impls by the virtue of MacroImplBinding
structures that are persisted between compilation runs serialized within
instances of macroImpl annotations.

Along with the evolution of our macro engine, we sometimes have to evolve
the format of MacroImplBinding, which means that it has to be versioned.
Version mismatches are checked upon every macro expansion, ensuring that
macros that we expand were compiled with exactly the same version of the
macro engine that we’re running.

That’s all really cool apart from the fact that version mismatches result
in aborting the entire compilation with an obscure message without giving
a hint about the culprits.

This commit improves the situation by providing pretty per-expansion
compilation errors that tell the programmer what macro expansions are
at fault and what macro engines were used to compile them.
manifests that Namers.mkTypeCompleter is flag-agnostic

When introducing `FlagAgnosticCompleter` and `FlagAssigningCompleter`,
I have overlooked the completers created in namers. These completers
only assign type signatures, not flags, because they are only created
for symbols originating from sources and such symbols have their flags
assigned based on modifiers and source def trees when they are entered.
unprivates important helpers in Namers.scala

This is the first of two commits that enable hooks necessary to implement
macro annotations in an honest, hackless compiler plugin.

This particular commit turns certain helpers into public methods. Of course,
there is a probability that with the evolution of macro paradise, I will need
more helper methods, and those will have to be called via reflection, but
at least for now it's nice to have a reflection-less plugin :)
hooks for naming and synthesis in Namers.scala and Typers.scala

Interestingly enough, despite of the implementation surface being
quite noticeable, it is enough to hijack just `enterSym` and typechecking
of stats for packages, templates and blocks in order to enable macro annotations.
That and `ensureCompanionObject`, which I couldn't abstract away so far.

An architectural note: given that a hooked method is called `X`,
there are two implementations of this method. `pluginsX` is defined in
AnalyzerPlugins.scala and lets macro plugins customize `X`.
`standardX` is defined next to `X` and provides a default implementation.
Finally `X` is changed to trivially forward to `pluginsX`.

Existing and future callers of `X` now can be completely oblivious of the
introduced hooks, because calls to `X` will continue working and will be
correctly hooked. This makes the infrastructure more robust.

The only downside is that in case when a macro plugin wants to call
into the default implementation, it needs to call `standardX`, because
`X` will lead to a stack overflow. However, in my opinion this not a big
problem, because such failures are load and clear + for every `pluginsX`
we actually provide documentation that says what is its standard impl is.
SI-7837 quickSort, along with Ordering[K], may result in stackoverflow because the code uses '==' instead of 'equiv'

== instead of equiv (from Ordering) was used by mistake.  Fixed.

Also created a test to make sure that == is not used by throwing an exception if it is (as suggested by Jason).
SI-7974 Avoid calling nonPrivateMember after erasure

One example were this would lead to subtle bugs otherwise is
Symbol_apply, where after erasure an overloaded symbol containing
Symbol#apply and UniquenessCache#apply is returned.

    // findMember considered harmful after erasure; e.g.
    //
    // scala> exitingErasure(Symbol_apply).isOverloaded
    // res27: Boolean = true
SI-7974 Clean up and test 'Symbol-handling code in CleanUp

Looks like the transformation did never happen because the pattern
failed to match. Why did the pattern fail to match? Because the
Symbol.apply we see in the tree claims to be a method while
Symbol_apply defined in Definitions wants to be a value.

This issue was caused because nonPrivateMember starts spitting out
overloaded symbols after erasure.
This issue has been fixed in the earlier commit, so what happens in
this commit is adding tests and fixing documentation.
SI-8102 -0.0.abs must equal 0.0

SI-8102 points out that -0.0.abs returns -0.0 (in error). The same issue
exists for -0.0f. This commit fixes the issue for both by delegating to
math.abs.
SI-8120 Avoid tree sharing when typechecking patmat anon functions

When typechecking an empty selector `Match` corresponding to:

    { case ... => ... }: (A => B)

We wrap it in a `Function` and typecheck:

    (x$1 => x$1 match { case ... => ... })

Local symbols in this expression (representing values bound by
the pattern, or just definitions in the body or guard) are then
owned by the anonymous function's symbol.

However, if we ever discard this `Function` and start anew with
the empty selector match, as happens during the fallback to
use a view on the receiver in `tryTypedApply`, we found that we
had mutated the cases of the original tree, and allowed orphaned
local symbols to escape into the compiler pipeline.

This commit uses duplicated trees for the the cases in the synthetic
`Match` to avoid this problem.

`duplicateAndKeepPositions` is used to preserve range positions;
without this scala-refactoring PrettyPrinterTest fails.
`Tree#duplicate` uses offset positions in the copied tree, which
is appropriate when both the original and the copy are going to end up
in the final tree.
awakens default getter synthesis from the untyper nightmare

Our happy little macro paradise is regularly invaded by resetAllAttrs,
the bane of all macros and typers. It’s so ruthless and devastating that
we’ve been long scheming to hack something really cool and to one day
defeat it.

Today we make the first step towards the happy future. Today we overthrow
the UnTyper, resetAllAttrs’s elder brother that rules in the kingdoms of
GetterLand and CaseClassia, and banish him from the land of getters.
In the name of what’s good and meta, let’s band together and completely
drive him away in a subsequent pull request!

To put it in a nutshell, instead of using untyper on a DefDef to do
default getter synthesis, the commit duplicates the DefDef and does
resetLocalAttrs on it.

As default getter synthesis proceeds with figuring out type and value
parameters for the getter, then its tpt and finally its rhs, the commit
destructures the duplicated DefDef and then assembles the default getter
from the destructured parts instead of doing copyUntyped/copyUntypedInvariant
on the original DefDef.

I would say the test coverage is pretty good, as I had to figure out
3 or 4 test failures before I got to the stage when everything worked.
Iirc it tests pretty exotic stuff like polymorphic default parameters
in both second and third parameter lists, so it looks like we're pretty
good in this department.