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.
update mailmap
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-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.
Optimize the pickler phase

 - move "erroneous type" diagnostic into a crash recovery handler,
    rather than running it proactively
 - move the "unexpanded macros" check into refchecks.

 Cuts this phase in half, from about 1% of compile time to 0.5%.
Merge pull request #3425 from retronym/ticket/7700

SI-7700 @unspecialized, Part Deux: Now Working.
SI-7124 make macro definitions prettier in scaladoc

Macros are now prettier in scaladoc, by
 - hiding the `macroImpl` annotation
 - showing the `macro` modifier in front
Merge pull request #3447 from retronym/topic/opt9

Optimize the pickler phase
Merge pull request #3444 from retronym/topic/opt6

Avoid generic collections operations hot paths
Merge pull request #3441 from gourlaysama/t7124

SI-7124 make macro definitions prettier in scaladoc
Merge pull request #3422 from adriaanm/mailmap

update mailmap
Merge pull request #3424 from som-snytt/issue/7322

SI-7322 Interpolator idents must be encoded