SI-8143 Regressions with override checks, private members

These regressed in e609f1f20b, which excluded all private methods from
overriding checks. We should only exclude private[this] members on the
low end of a pair, as was done before that commit, and, we must also
exclude private members on the high side.

Why? Warning: reverse engineered intuition follows.

We need to report an error when if a private method in a subclass
has matches a less-private method in the super class and report an
error, lest the user be fooled into thinking it might be invoked
virtually. On the other hand, adding a private method to a super
class shouldn't invalidate the choice names of public members in
its superclasses.

I've removed the test case added by that commit and will lodge a
reworked version of it that Paul provided as a new issue. That shows
a bug with qualified private + inheritance.

In addition, the expectation of `neg/accesses.check` is reverted
to its 2.10.3 version, which I believe is correct. When it was
changed in e609f1f20b it sprouted a variation, `neg/accesses-2`,
which has now changed behaviour. The intent of that test will
be captured in the aforementioned issue covering qualified private
inheritance.
Scaladoc jars should go to /api.
Remove cruft from pom.

My understanding is distributionManagement is only needed to configure
maven locally for publishing. Since we do that it ant, getting rid of it.
SI-8170 Fix regression in TypeRef#transform w. PolyTypes

Regressed in SI-8046 / edc9edb7, by my hand.

At the time, I noticed the problem: transform wasn't accounting
for the potential Poly-Type-ness of its argument, and this would
lead to under-substituted types. The commit comment of edc9edb7
shows an example.

But the remedy wasn't the right one. The root problem is
that a TypeMap over a PolyType can return one with cloned
type parameter symbols, which means we've lose the ability
to substitute the type arguments into the result.

This commit detects up front whether the type-under-transform
is a PolyType with the current TypeRef's type parameters, and
just runs the `asSeenFrom` over its result type.
Prohibit views targeting AnyVal

Library changes in Scala 2.10 mean that we are left with the
unfortunate situation of admitting:

    scala> "": AnyVal
    res0: AnyVal =

 We already have explicit checks in place to prevent views
 targeting `AnyRef`. This commit balances this out by prohibiting
 `AnyVal`, as well.

The enclosed test shows that this case is now prevented. If multiple
implicits views are applicable, the ambiguity error is still raised;
these check comes right at the end. Maybe that ought to be changed,
but I don't think it matters too much.

I've also disabled this prohibition under -Xsource:2.10.
update mailmap
SI-8199 Account for module class suffix in -Xmax-classfile-name

The class file name of an inner class is based on the flattened
name of its owner chain.

But, if this is going to be unreasonably long, it is shortened
with the help of a MD5 hash.

However, after this shortening takes place, we sneakily add one
more character (the infamous '$') to the name when it is used
for the module class. It is thus possible to exceed the limit
by one.

The enclosed test failed on Mac with "filename too long" because
of this. I have also tested for trait implementatation classes,
but these seem to be suffixed with "$class" before the name
compactification runs, so they weren't actually a problem.

This change is binary incompatible as separately compiled
defintions and usages of named, inner classes need to agree
on this setting. Most typically, however, these long names
crop up for inner anonymous classes / functions, which are
not prone to the binary incompatiblity, assuming that their
creation hasn't be inlined to a separately compiled client.
Merge pull request #3426 from retronym/ticket/8199

SI-8199 Account for module class suffix in -Xmax-classfile-name
SI-8205 Avoid long, slow march to AIIOBE in SourceFile#lineContent

Fixing a regression from SI-8015.

The failure mode is kind of amusing: a while loop in `lineToString`
would count all the way to `Int.MaxValue`, and integer overflow
would foil a bounds check when looking for the 'LF' in 'CR'-'LF'.

Given that we're not a style checker to enforce that source files
end in a new-line, this commit accounts for EOF, and fixed the
overflow problem too.

A JUnit test exercises the bug and a few other variations of
`lineContent`.

While i was in the neighbourhood, I opted for a more efficient
means to slice out that line.
Merge pull request #3427 from retronym/ticket/8205

 Avoid long, slow march to AIIOBE in SourceFile#lineContent
SI-7322 Interpolator idents must be encoded

Otherwise, they are not found.

This matters for term names with a differential encoding.

Footnote, normally ident() encodes, but INTERPOLATIONID
is !isIdent, so that is not used here.  Maybe that would
be the better improvement.
SI-8205 Don't include CR in line

More penance. Extend the unit test and don't include CR
in the line text.

This is obvious, which shows how dangerous it is to refactor
without unit tests.

My very favorite bugs are off-by-one and EOL handling, followed
closely by off-by-Int.MaxValue.
Merge pull request #3429 from som-snytt/issue/8205

SI-8205 Don't include CR in line
SI-8213 AnyRefMap.getOrElseUpdate is faulty

Altered getOrElseUpdate to be robust to the map changing out from under it as a result of calling the default value method.  Side-effects FTW!

Made a comparable change in LongMap also, as it was also affected.  And added a test to SetMapConsistencyTest.
Merge pull request #3416 from retronym/topic/any-val-implicit

Prohibit views targeting AnyVal
Merge pull request #3434 from Ichoran/issue/8213

SI-8213 AnyRefMap.getOrElseUpdate is faulty
Improve ExecutionContext implicitNotFound and docs

It is not good practice to import a specific ExecutionContext
all over the place; we shouldn't recommend that. People should
allow callers to specify the context in most cases and only
import the context in some central location in their code.

While we are at it, add some more comprehensive docs to
ExecutionContext which will hopefully give people enough understanding
to make decisions about it.
SI-7700 @unspecialized, Part Deux: Now Working.

This annotation was introduced to allow us to mark methods within
a specialized trait as immune from specialization. In particular,
this is desirable for `Function1.{andThen, compose}`.

However, it seems we need to check for this in two places in the
specialization code base. The feature is now backed with a test.
Merge pull request #3357 from retronym/ticket/8143

SI-8143 Regressions with override checks, private members
Avoid generic collections operations hot paths

 - Use a specialized version of List#{map, collectFirst}
   These special case mapping over an empty list and avoid
   allocating.
 - Avoid nonEmpty in favor of `ne Nil`

I see in the order of 2% speedup.

Perhaps more useful is that
these methods no longer dominate the YourKit profiles, even though
profiler bias due to safepoints at allocation of the ListBuffer
might have been overstating their significance.