Move tracing macro out of partest, closer to user

Ideally, the `tracing` macro would be factored out to a library of testing
macros shipped with partest (as originally done in c619f94a).

Unfortunately, our macro implementation is not stable enough to invoke a macro
that was compiled with an older version, say 2.11.0-M3. More precisely,
compatibility with M3 was broken when the pickling of macro bindings changed in
82f0925b69.

As we want to move partest to its own project and compile it with a released
version of Scala, we must start anticipating this build sequence by building
partest with a released starr&locker while using the quick compiler to compile tests.
Make stability-test configurable in builds to diff.
Add restrap step when skipping locker

If we don't build locker, we must take an additional bootstrap step,
so that we can test stability. More precisely, we want to ensure that,
for the given compiler sources, the same bytecode is generated when:

  1. We build a new compiler for given sources with the STARR compiler
    and then use that compiler to build the sources of {library|reflect|compiler}.
  2. We build a new compiler for given sources with the compiler
    that results from building a new compiler with the STARR compiler,
    and then use that compiler to build the sources of {library|reflect|compiler}.
Flip defaults: use released STARR and skip locker.

No longer build locker by default.
The STARR compiler builds the "quick" compiler,
where STARR is a released version of Scala
(specified in the property file `starr.number`).

You can opt out using:

```
locker.enable=1
starr.custom=1
```

The first option enables building locker, using it to build quick.
The second line downloads a custom, unreleased, STARR.

This new behavior used to be opt-in via:

```
locker.skip=1
starr.use.released=1
```
Use Scala 2.11.0-M3 to build the compiler.