Fix Iterator#copyToArray (fixes SI-6827).

As pointed out in #scala, when using a non-zero start it's possible
to get an ArrayIndexOutOfBoundsException due to an incorrect bounds
check. This patch fixes this, as well as another potential bounds
error, and adds test cases.

Incorporates some other suggestions by Som-Snytt to ensure that
callers will get useful error messages in cases where the start
parameter is wrong (negative or out-of-array-bounds).

Review by @som-snytt.
bind + argc specialization = 20x perf boost

Default logic of mirror construction, which gets triggered via
reflectField/reflectMethod/reflectConstructor, validates a lot of facts
about its arguments.

This takes quite a bit of time, which significantly degrades performance
of reflection-heavy applications. Proposed two changes provide an order
of magnitude performance boost to a simple app, which repeatedly invokes
the same method for different receiver instances.
a few performance improvements for toArray

First of all the typo I have made when migrating from manifests to tags.
`repr.getClass` in `WrappedArray` should read `array.getClass`.

Secondly manifests for Any, Object/AnyRef, AnyVal, Null and Nothing
now have their `newArray` methods overridden to avoid reflective overhead
of array instantiation.
Eliminate allocations in ListBuffer.

++= on a linear sequence can be accomplished without
closure allocation.
Eliminate allocations in ClassfileParser.
Eliminating more allocations in the collections.
Eliminating allocations in Codec.
Eliminating allocations in typeDepth.
Eliminate allocations in Growable.
Eliminate allocations in TypeMap.
Eliminate allocations in CPSAnnotationChecker.
Eliminate allocations in BaseTypeSeqs.
Eliminate allocations in uncurry and the backend.
Eliminate allocations in Trees.
Eliminate allocations in Specialize.
Eliminate allocations in Trees and Symbols.
Eliminate allocations in Types.

At this commit the statistics when compiling src/library
are as follows. These counts are precise, collected by a
modified Function1 which counts every instantiation of every
implementing class. The net result is 27 million fewer
allocations, over a 20% drop.

  // master (5b5635ee9d), total and top five by count:
  Total Function1 allocations: 128,805,865

  scala.collection.immutable.$colon$colon 26781958
  scala.collection.mutable.ListBuffer 15365174
  scala.collection.TraversableLike$$anonfun$map$1 9127787
  scala.collection.generic.Growable$$anonfun$$plus$plus$eq$1 4636154
  scala.collection.mutable.StringBuilder 3531211

  // After these commits, total and top five by count:
  Total Function1 allocations: 101,865,721

  scala.collection.immutable.$colon$colon 26993704
  scala.collection.mutable.ListBuffer 15319656
  scala.collection.TraversableLike$$anonfun$map$1 7585019
  scala.reflect.internal.Types$MethodType$$anonfun$paramTypes$1 2447307
  scala.reflect.internal.Types$SubstSymMap 2436088
fusion of loops in Range.foreach() and Range.validateRangeBoundaries()

This commit allows closure elimination in more cases. The non-inlined case also benefits from saving a Range.validateRangeBoundaries() invocation.

Before this commit, the closure argument to Range.foreach() escaped to Range.validateRangeBoundaries(). As a consequence, closure elimination required inlining both of them. Given that the current optimizer duplicates a closure body whenever that closure's apply() is invoked, the resulting code size taxed the JIT compiler. In particular when apply() delegates to a specialized version, or when a bridge apply() stands in the way.
nested closures are flattened by calling supplementErrorMessage() directly

A closure C that becomes an argument to the constructor of another closure makes both closures harder to eliminate (either by scalac-optimizer or JIT-compiler) than is the case when C is the argument to an @inline method.
Merge pull request #1823 from paulp/pr/eliminate-allocations

Eliminating allocations.