Reworked runner.
Regenerated primitive types without (String)String methods.

That's right, even after removing any2stringadd scala was
glad to accept expressions like 1 + "bob" because it infects
all the primitive types with synthetic (String)String methods.
We've disinfected:

scala> 1 + "bob"
<console>:14: error: overloaded method value + with alternatives:
  (x: Double)Double <and>
  (x: Float)Float <and>
  (x: Long)Long <and>
  (x: Int)Int <and>
  (x: Char)Int <and>
  (x: Short)Int <and>
  (x: Byte)Int
 cannot be applied to (String)
              1 + "bob"
                ^
Removed the "magical" String.+ method.

This was defensible when it was written, but there are better
ways to do this sort of thing now. Those ways aren't included
in this commit but perhaps I can find a volunteer. The first
thing to try I think is a fasttrack macro which flattens a series
of string concatenations into the usual StringBuilder business.

For now we'll live with a value class which is efficient when
adding two strings but less so with more. It would be nice if
we could return StringAddition from `+` instead of String as
this would solve all our performance problems, though at some
cost in sketchiness if we opted to edit the buffer in-place
assuming a "poor man's linear type". That sketchiness is moot
though because:

  val x = "a" + b + c + d

If the type of x isn't inferred as String, too much will break.
An implicit from StringAddition back down to String will only have
any effect if x is ascribed as String. I can think of a lot of ways
to make this work, but none will be possible in normal scala
because it offers no means of influencing type inference.

Fortunately we need not suffer scala's limitations.
The source/test changes necessitated by removing String.+.

There is still at least one material test failure:
constant folding in annotation arguments was bound up in
String.+ somewhere and now it doesn't work. See failing
test pos/annotations.scala.

Here's a look at the (temporary) impact of the change.

  class Bob {
    override def toString = "Bob"
  }
  object Test {
    val b, c = new Bob
    def x = "Hi, " + b + c
  }

-- Bytecode for method x under -optimise --

Reigning hardcoding champion, scala 2.11:

//  0: new           #25   // class StringBuilder
//  3: dup
//  4: invokespecial #26   // Method StringBuilder."<init>"
//  7: ldc           #28   // String Hi,
//  9: invokevirtual #32   // Method StringBuilder.append
// 12: aload_0
// 13: invokevirtual #34   // Method b:()LBob;
// 16: invokevirtual #32   // Method StringBuilder.append
// 19: aload_0
// 20: invokevirtual #36   // Method c:()LBob;
// 23: invokevirtual #32   // Method StringBuilder.append
// 26: invokevirtual #39   // Method StringBuilder.toString
// 29: areturn

The challenger, policy no-stable-version-yet:

// Note that the first 12 bytes of bytecode is useless implicit
// residue, a decent inliner (and better object loading semantics)
// could eliminate it.
//
//  0: getstatic     #28  // Field scala/StringAddition$.MODULE$
//  3: getstatic     #33  // Field scala/Predef$.MODULE$
//  6: getstatic     #28  // Field scala/StringAddition$.MODULE$
//  9: getstatic     #33  // Field scala/Predef$.MODULE$
// 12: astore_1
// 13: ldc           #35  // String Hi,
// 15: aload_0
// 16: invokevirtual #37  // Method b:()LBob;
// 19: invokevirtual #41  // Method scala/StringAddition$.$plus$extension
// 22: astore_3
// 23: astore_2
// 24: aload_3
// 25: ifnull        32
// 28: aload_3
// 29: goto          34
// 32: ldc           #43  // String null
// 34: aload_0
// 35: invokevirtual #45  // Method c:()LBob;
// 38: invokevirtual #41  // Method scala/StringAddition$.$plus$extension
// 41: areturn

Clearly policy loses, but it's not the bloodbath you might expect.
We'll reassess after the macro-rena.
bootstrap compiler 1.0.0-M7.
Add @uncheckedPure annotation.

https://groups.google.com/d/msg/scala-internals/gymfMndvFLc/sRlOU2UThloJ

Summarizing excerpt:

  Why, you might ask, are we obtaining a static reference to
  Predef$.MODULE$ only to cast it aside unused? The reason is that
  Predef is an object, and objects are lazily loaded, and therefore
  every single call to Predef is potentially side-effecting (as far as
  the optimizer understands) and can never be eliminated.  Even after we
  have eliminated the method call itself.
  ...
  We could eliminate the Predef$ no-ops in the short-term if we only had
  an annotation for objects ("@pure") which allowed the optimizer to
  assume that loading them is side-effect free.

Typical example of impact, full source of the method
is in policy/src/test/scala/pure.scala.

// scala 2.11.2              // policy
//                           //
//  0: getstatic     #25     //  0: dload_3
//  3: getstatic     #30     //  1: sipush        1000
//  6: astore        5       //  4: i2d
//  8: dload_3               //  5: dmul
//  9: sipush        1000    //  6: dstore        5
// 12: i2d                   //  8: dload_1
// 13: dmul                  //  9: dload         5
// 14: dstore        7       // 11: dmul
// 16: astore        6       // 12: dreturn
// 18: dload_1
// 19: dload         7
// 21: dmul
// 22: dreturn

The total impact on policy is about 175K of bytecode eliminated,
as measured by summing all classfiles sizes. This is not especially
relevant in the large but can be very important in hot methods
due to thresholds like the 35-byte hotspot inlining ceiling.
Test-related fiddling.

Looks like I unwittingly moved poor ScalaReflectionException.