Don't use the BrowsingLoader for Java sources. 

When the presentation compiler needs a SourceLoader, instead of immediately adding the file 
to the compilation round it uses a fast parser to create symbols for all top-level class definitions. 
The fast parser assumes Scala sources, which is not always the case.
Don't require symbols to be loaded in the parser.

The parser special-cases primitive types. For comparing the name, it relied on having the symbols 
for primitive types already loaded, which is not always the case. The presentation compiler 
may parse sources for, say, scala.Int, and therefore the symbol for Int may not be yet available.
Remove NPE when `compileLate` sees sources during initialization.

When a symbol needed in Definitions is loaded, it may be that the corresponding source is newer than
the classfile. That will send it to `compileLate`, but no phase is yet set. We simply add it to the 
compilation pipeline and continue gracefully.
SI-2807 Resurrect and refine the promiscuous catch warning.

The previous incarnation didn't survive 4fb3473.

This version can be cleared by using a typed pattern: `catch { case _: Throwable => }`.

This is motivated by the recent appearance of such a catch in `util.Try`, and by battle
scars left by one too many processes bravely but stupidly catching and logging OutOfMemoryErrors.

-Y status has been skipped: this warning is enabled by default and can only be silenced
with use of a typed pattern.
Fix SI-5284.

The problem was the false assumption that methods specialized
on their type parameter, such as this one:

    class Foo[@spec(Int) T](val x: T) {
      def bar[@spec(Int) S >: T](f: S => S) = f(x)
    }

have their normalized versions (`bar$mIc$sp`) never called
from the base specialization class `Foo`.
This meant that the implementation of `bar$mIc$sp` in `Foo`
simply threw an exception.

This assumption is not true, however. See this:

    object Baz {
      def apply[T]() = new Foo[T]
    }

Calling `Baz.apply[Int]()` will create an instance of the
base specialization class `Foo` at `Int`.
Calling `bar` on this instance will be rewritten by
specialization to calling `bar$mIc$sp`, hence the error.

So, we have to emit a valid implementation for `bar`,
obviously.
Problem is, such an implementation would have conflicting
type bounds in the base specialization class `Foo`, since
we don't know if `T` is a subtype of `S = Int`.
In other words, we cannot emit:

    def bar$mIc$sp(f: Int => Int) = f(x) // x: T

without typechecking errors.

However, notice that the bounds are valid if and only if
`T = Int`. In the same time, invocations of `bar$mIc$sp` will only
be emitted in callsites where the type bounds hold.
This means we can cast the expressions in method applications
to the required specialized type bound.

The following changes have been made:
1) The decision of whether or not to create a normalized
version of the specialized method is not done on the
`conflicting` relation anymore.
Instead, it's done based on the `satisfiable` relation,
which is true if there is possibly an instantiation of
the type parameters where the bounds hold.
2) The `satisfiable` method has a new variant called
`satisfiableConstraints`, which does unification to
figure out how the type parameters should be instantiated
in order to satisfy the bounds.
3) The `Duplicators` are changed to transform a tree
using the `castType` method which just returns the tree
by default.
In specialization, the `castType` in `Duplicators` is overridden,
and uses a map from type parameters to types.
This map is obtained by `satisfiableConstraints` from 2).
If the type of the expression is not equal to the expected type,
and this map contains a mapping to the expected type, then
the tree is cast, as discussed above.

Additional tests added.

Review by @dragos
Review by @VladUreche

Conflicts:

	src/compiler/scala/tools/nsc/transform/SpecializeTypes.scala
	src/compiler/scala/tools/nsc/typechecker/Duplicators.scala
Fix SI-4809.
Merge pull request #712 from dragos/issue/hardening-compiling-with-newer-sources

Issue/hardening compiling with newer sources
Merge pull request #752 from retronym/topic/warn-catch-all-4

SI-2807 Resurrect and refine the promiscuous catch warning.
Merge pull request #755 from axel22/issue/5284-cherry-picked

Fix SI-5284.
Merge pull request #756 from axel22/issue/4809

Fix SI-4809.
GlobalAssist.

Sounds like a charity.
Merge branch 'master' into prime-merge

* master:
  Fix SI-4809.
  Fix SI-5284.
  SI-2807 Resurrect and refine the promiscuous catch warning.
  Remove NPE when `compileLate` sees sources during initialization.
  Don't require symbols to be loaded in the parser.
  Don't use the BrowsingLoader for Java sources.

Conflicts:
	src/compiler/scala/tools/nsc/ast/parser/Parsers.scala
	src/compiler/scala/tools/nsc/symtab/BrowsingLoaders.scala
	src/compiler/scala/tools/nsc/transform/Constructors.scala
	src/compiler/scala/tools/nsc/transform/SpecializeTypes.scala
	src/compiler/scala/tools/nsc/typechecker/Duplicators.scala
	test/files/continuations-neg/trycatch2.scala
	test/files/pos/spec-params-new.scala
Merge branch 'topic/global-assist' into prime-merge

* topic/global-assist:
  GlobalAssist.