Restrict Import-Package for scala.*

Restrict the Import-Package OSGi manifest entry to match only binary compatible scala.* packages. This is necessary, because the Scala OSGi versions do not match the OSGi semantic versioning policy and are not binary compatible between their OSGi minor versions. This means that e.g. the scala-compiler-2.11 bundle will never work if it imports a scala.* package from 2.10 or 2.12. Thus this patch enforces a tight version range, only accepting versions within the same minor version. E.g. Applied to version 2.11.1 the range would expand to "[2.11,2.12)".

Additionally, a Java 6 execution environment will be enforced for OSGi.

All module bundles need to have their own version numbers. This was not the case before this commit. Although these module bundles were only build for testing, they are needed to be correct, now, that we have stricter package import constraints and some test cases rely on them.
Add JavaSE-1.7 to set of required execution environments.

Without it, Equinox on Java 7 might spit out some warnings, which might lead to the wrong impression, that the Scala bundles are not well supported for newer platforms.
Refined package imports for scala modules.

Made scala.xml.* import optional and removed scala.util.parsing.json import.
Re-added the scala.util.parsing package import, with optional resolution.
SI-8475 Fix off by one in GroupedIterator when Streaming

This also affected sliding and grouped since they defer to GroupedIterator
TypeTree printing modified (SI-8447)
SI-8553 WrappedArray throws exception on lastIndexWhere when index out of range

Adds a check in `IndexedSeqOptimized#lastIndexWhere(A => Boolean, Int)`
to begin searching in the end of the collection if `end` is greater than
the collection's length.

Discussed in
https://groups.google.com/d/topic/scala-internals/-MacXivbY0Q/discussion.
SI-8507 Avoid lazy val in StringContext

This mild refactor eliminates the lazy val StringBuilder
and arguably makes the code easier to read.

There is a small unit test but no benchmark to prove
anything useful about performance. The ticket notes
contention due to lazy implementation.
SI-8185 Correct grammar for single-warning compilation run
SI-8587 Explicitly document forall/exists for empty collections

This behaviour isn't always intuitive for newcomers.

Also changes inadvertant doc comment to an impl. comment.
SI-8591 Scaladoc: Problem with scrolling under Safari on iOS
SI-8574 Copy @SerialVersionUID, etc, to specialized subclasses

The test case demonstrates that this is important for serialization
and for strictfp. (Although the latter is still pretty broken,
see SI-7954.)

Now that the synthetic subclass of `Tuple2[Int, Int]` also has the
`@deprecatedInheritance` annotation, I had to change the spot that
issues this warning to be silent after the typer phase. Otherwise,
we get two warnings in `run/t3888.scala`. This also remedies double
warnings that were incurred in `neg/t6162-inheritance`.
Merge pull request #3738 from retronym/ticket/8574

SI-8574 Copy @SerialVersionUID, etc, to specialized subclasses
SI-8601 Don't treat int/long division, or arraylength, as dead-code

`{i, l}div` and `{i, l}rem` throw an `ArithmeticException` if the
divisor is 0.

`arraylength` throws a `NullPointerException` on a null reference.

JVM Spec:
> The only integer operations that can throw an exception are the
> integer divide instructions (idiv and ldiv) and the integer
> remainder instructions (irem and lrem), which throw an
> ArithmeticException if the divisor is zero.

> The Java virtual machine's floating-point operators do not throw
> runtime exceptions

> If the arrayref is null, the arraylength instruction throws a
> NullPointerException.

I checked the other primitives in `ICode` to see if anything else
should be considered as live code.

Pure:

	  // jvm  : {i, l, f, d}neg
	  case class Negation(kind: TypeKind) extends Primitive
	  // jvm  : if{eq, ne, lt, ge, le, gt}, if{null, nonnull}
	  //        if_icmp{eq, ne, lt, ge, le, gt}, if_acmp{eq,ne}
	  case class Test(op: TestOp, kind: TypeKind,  zero: Boolean)  extends Primitive
	  // jvm  : lcmp, {f, d}cmp{l, g}
	  case class Comparison(op: ComparisonOp, kind: TypeKind) extends Primitive

Impure: {i, l}{div, rem}, otherwise pure

	  // jvm  : {i, l, f, d}{add, sub, mul, div, rem}
	  case class Arithmetic(op: ArithmeticOp, kind: TypeKind) extends Primitive

Pure (overflow is silent, NaN.toInt is defined):
	  // jvm  : {i, l}{and, or, xor}
	  case class Logical(op: LogicalOp, kind: TypeKind) extends Primitive

	  // jvm  : {i, l}{shl, ushl, shr}
	  case class Shift(op: ShiftOp, kind: TypeKind) extends Primitive

	  // jvm  : i2{l, f, d}, l2{i, f, d}, f2{i, l, d}, d2{i, l, f}, i2{b, c, s}
	  case class Conversion(src: TypeKind, dst: TypeKind) extends Primitive

Impure! May NPE!

	  // jvm  : arraylength
	  case class ArrayLength(kind: TypeKind) extends Primitive

Pure (we know that StringBuilder.{<init>, append, toString} are pure
and `append` is null safe.)

	  // jvm  : It should call the appropiate 'append' method on StringBuffer
	  case class StringConcat(el: TypeKind) extends Primitive

	  // jvm:  it should create a new StringBuffer
	  case object StartConcat extends Primitive

      // jvm:  convert StringBuffer to a String
	  case object EndConcat extends Primitive
SI-8601 Avoid over-eager optimization of LOAD_FIELD

It can NPE or trigger static class initilization, we can't elimiate
it without changing semantics.
Add a test for array load
SI-8601 Don't treat newarray as dead code

Otherwise we lose the side effect of a `NegativeArraySizeException`.
SI-8601 Test that `null.synchronized` NPEs under -optimize

As part of my sweep through the side-effecting byte code instructions.
Bump akka-actor version to 2.3.3 (ref SI-8549)

Because serialization affected akka, we're upgrading the included
akka-actor to 2.3.3, which is built with Scala 2.11.1.
Merge pull request #3760 from retronym/ticket/8601

Reining back over-eager optimizations.