SI-8153 Mutation is hard, let's go shopping with an empty list

Changed the implementation of iterator to be more robust to mutation of the underlying ListBuffer.

Added a test to make sure bug is gone.

Fixed an "unsafe" usage of ListBuffer.iterator in the compiler, and added a comment explaining the (new) policy for iterating over a changing ListBuffer.

The compiler now uses a synchronized-wrapped ArrayBuffer instead of ListBuffer, as that makes the (custom) units Iterator more natural to write (and avoids O(n) lookups).
SI-8280 regression in implicit selection.

In 2fa2db7840 I fixed a bug where applicable implicit conversions
would not be found for numeric types if one introduced any aliasing
or singleton types, for the usual reasons involving the absence of
uniform type normalization. See pos/t7228 for examples - that test
case has 20 errors in 2.10.3 but compiles in master.

An unintended side effect was making implicit search less oblivious.
It turns out that in so doing I had created ambiguity where there was
none before. Not because it was any more ambiguous, but because the
compiler now had the wits to notice the ambiguity at an earlier time.

The fix for this is not intuitive. The way the internal logic is,
we need to keep the wool over implicit search's eyes, which leads
to those unrecognized types being passed to adapt, where they are
recognized and weak subtyping suffices to be more specific. It is
sufficient for SI-7228 that weak subtyping be done correctly - the
other change, which is reverted here, was exposing the type arguments
of Function1 when a view exists as a subtype of Function1.

It is also possible this could be remedied by calling weak_<:<
somewhere which is presently <:<, but I don't know where and it
has a far greater chance of affecting something else than does
this, which is a straight reversion of a post-2.10.3 change.
SI-8276 Test for cyclic error caused by (reverted) SI-1786 fix

We reverted SI-1786 recently on the grounds that its means of
avoiding cycles (not sharpening bounds of T[_] when T is
uninitialized) caused unacceptable non-determinism (well:
compilation order dependency) to type inference.

Nary a day later, @gkossakowski hit a regression in scala-io.
Bisection revealed that it stopped working in 2dbd17a2 and
started working agiain after the revert. How's that for
prescience!

I've distilled the cyclic error in scala-io in this test
case.

I'm yet to pinpoint this, followon error, which didn't survive
the shrink ray, and only appeared in the original code:

    error: java.lang.IndexOutOfBoundsException: 0
	at scala.collection.LinearSeqOptimized$class.apply(LinearSeqOptimized.scala:51)
	at scala.collection.immutable.List.apply(List.scala:83)
	at scala.reflect.internal.tpe.TypeMaps$AsSeenFromMap.correspondingTypeArgument(TypeMaps.scala:5
Merge pull request #3524 from paulp/pr/8280

SI-8280 regression in implicit selection.
SI-6632 ListBuffer's updated accepts negative positions

Changed the behavior in SeqLike.updated (which would silently accept negatives and throw on empty.tail) to throw IndexOutOfBoundException.

Updated tests to verify the behavior in ListBuffer.  Everything else SeqLike will come along for the ride.
SI-8177 specializeSym must use memberInfo on high side

When determining whether member `symLo` of `tpLo`
has a stronger type than member `symHi` of `tpHi`,
should we use memberType or memberInfo?

Well, memberType transforms (using `asSeenFrom`) `sym.tpe`,
whereas memberInfo performs the same transform on `sym.info`.
For term symbols, this ends up being the same thing (`sym.tpe == sym.info`).
For type symbols, however, the `.info` of an abstract type member
is defined by its bounds, whereas its `.tpe` is a `TypeRef` to that type symbol,
so that `sym.tpe <:< sym.info`, but not the other way around.

Thus, for the strongest (correct) result,
we should use `memberType` on the low side.

On the high side, we should use the result appropriate
for the right side of the `<:<` above (`memberInfo`).

I also optimized the method a little bit by avoiding calling memberType
if the symbol on the high side isn't eligble (e.g., it's a class).

PS: I had to add a workaround to reifyType, because
we now dealias a little less eagerly, which means
a type selection on refinement class symbols makes it to reify
this broke the t8104 tests.
I also had to update the run/t6992 test, which should now test the right thing.
Tests should be commented and/or use sensible names.
What is it testing? What is the expected outcome? We should not be left guessing.
SI-8188 NPE during deserialization of TrieMap

The writer was using the constructor headf and ef instead of the internal vars hashingobj and equalityobj.
Merge pull request #3526 from retronym/ticket/1786-cycle

SI-8276 Test for cyclic error caused by (reverted) SI-1786 fix
Merge pull request #3376 from Ichoran/issue/8153

SI-8153 Mutation is hard, let's go shopping with an empty list
SI-8177 tidy up in type reification
SI-8283 mutation-free bound inference for existentials

A safer version of the fix for SI-6169 (#3471)

Only modify the skolems to avoid leaking the sharper bounds to `quantified`.

The included test case was minimized from akka-camel
(src/main/scala/akka/camel/Consumer.scala).
Merge pull request #3525 from adriaanm/t8177b

SI-8177 specializeSym must use memberInfo on high side
Merge pull request #3530 from Ichoran/issue/6632

SI-6632 ListBuffer's updated accepts negative positions
Merge pull request #3531 from Ichoran/issue/8188

SI-8188 NPE during deserialization of TrieMap
Merge pull request #3533 from adriaanm/t8283

SI-8283 mutation-free bound inference for existentials