Revert "Implement @static annotation on singleton object fields."

This reverts commit 892ee3df93a10ffe24fb11b37ad7c3a9cb93d5de with
exception of keeping `@static` annotation in the library so we
can deploy a new starr that does not depend on it before removing
it completely.

Conflicts:

	src/compiler/scala/tools/nsc/backend/icode/GenICode.scala
	src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala
	src/compiler/scala/tools/nsc/transform/CleanUp.scala
Merge pull request #1291 from vjovanov/actor-migration-tests

Fix for SI-6305 & new actor migration tests 
SI-6287 fixes synthetic symbol clashes in toolbox

Apparently synthetic classes like $anonfun$1 have two properties:
1) Their names are generated using a counter unique to a compilation unit
2) After flatten they levitate to the nearest enclosing package

As a result if we use an empty package to wrap toolbox codegen,
then this package will soon be overflown by $anonfun$1 symbols, because:
1) New codegen session = new compilation unit = new counter which starts at 0
2) New codegen session = new anon funs that end up as children of empty package

Creating a freshly named package for each codegen session fixed the problem.
Now anonfuns from different sessions end up with different parents.
SI-5942 toolboxes now reset front ends

FrontEnd => Reporter proxy now correctly redirects
flush and reset back to the underlying front end.
SI-5692 better error message

Doesn't fix the underlying issue with macros and type inference,
but at least now the error message says exactly what needs to be done
to make the error go away.
pull request feedback
Merge pull request #1249 from vigdorchik/cleanup_shadowing_table

Cleanup makeShadowingTable, save some memory. Review by @VladUreche or @...
Merge pull request #1328 from scalamacros/ticket/5942

SI-5942 toolboxes now reset front ends
Merge pull request #1329 from scalamacros/ticket/5692

SI-5692 better error message
Removed many @inline annotations and final modifiers.

It is my belief that these @inlines and finals landed between
unhelpful and harmful. I am sure this will be disputed in some
cases. It's too much and too difficult to measure except in the
aggregate unless we have specific @inline sites to discuss.
I don't know upon whom the burden of proof lies.  I think we
should err on the side given here, since there is no evidence
of any consistent rationale being applied and it is easy to
verify the negative impact scala compiler inlining can have on
hotspot's far more sophisticated inlining.
improved reflection documentation
enable integer multiplication/divison on FiniteDuration, see SI-6389

- without this "2.seconds * 2" will not return FiniteDuration but
  Duration
- added test case verifying this behavior
- matches normal arithmetics: integers throw on div-by-zero while
  doubles yield infinity; extended here to include overflow protection
  on integer multiplication
New starr that does not depend on `@static`.

Deployed a new starr that does not depend on `@static` annotation.
The next step will be deleting `@static` from the library
altogether.
existentially typed expansions now work fine

If one tries to compile the following code with the parent of this commit:

  ru.reify(new Object().getClass)

then the following error will occur:

  Test.scala:2: error: type mismatch;
    found   : $u.Expr[Class[_ <: Object]]
    required: reflect.runtime.universe.Expr[Class[?0(in value <local Test>)]]
              where type ?0(in value <local Test>) <: Object
    ru.reify(new Object().getClass)
            ^

This happens because macro expansions are always typechecked against the
return type of their macro definitions instantiated in the context of expandee.

In this case the expected type contains skolems which are incompatible
with wildcards in the type of the expansion.

I tried all the incantations I could think of - without any success.
Luckily I met Martin who pointed me at the same problem solved in adapt
(see the diff w.r.t Typers.scala).
Remove `@static` annotation from the library.

It's a follow-up commit on 4bfcadabae7663e4329f5a4b21a9368477a7e3e3.
test case closes SI-5418

Now, when the existential reification bug is fixed, I've been able
to take a look at SI-5418, and, apparently, the problem with importers
has fixed itself during these 9 months of the bug being active.
clarify caveats of App trait
SI-6336 Now also catches return types

As Mark's comments on SI-6336 shows, we also need to disallow value classes
as return types of structural types.
Merge pull request #1340 from gkossakowski/revert-static-annotation

Revert `@static` annotation
Merge pull request #1298 from pavelpavlov/SI-5767

SI-5767 fix + protecting public FlatHashMap API