SI-6555 Better parameter name retention

We were losing track of parameter names in two places:

  1. Uncurry was using fresh names for the apply method
     parameters during Function expansion. (The parameter names
     in the tree were actually correct, they just had synthetic
     symbols with "x$1" etc.)
  2. When adding specialized overrides, the parameter names
     of the overriden method were used, rather than the parameter
     names from the overriding method in the class to which we are
     adding methods.

The upshot of this is that when you're stopped in the debugger in
the body of, say, `(i: Int) => i * i`, you see `v1` rather than `i`.

This commit changes Uncurry and SpecializeTypes to remedy this.
DRYer crash reports.

 - Add the supplementary message only once per run, so we don't
   output the same information as we bubble up through a sequence
   of well-intentioned exception handlers.
 - In Driver, don't report message of a `FatalException`
   immediately after reporting the message and stack trace.
    - Rename `logThrowable` to `reportThrowable`, which is what it
      actually does.

The difference in output is visible:

  https://gist.github.com/4242138
SI-5841 reification of renamed imports

Reification of renamed imports is done by catching Selects with name != their tree.symbol.name,
replacing this name with tree.symbol.name, and then doing reifyProduct in case
of renamed terms and reifyBoundType (inner) in case of renamed types.
Cleanups of reifyBoundTerm and reifyBoundType

Cases in reifyBoundTerm are merged by constructors; conditions in reifyBoundType are linearized;
also, in latter, or-patterns are used to merge some cases;
and some minor stuff not worth mentioning.
Merge pull request #1752 from scalamacros/ticket/5841

Ticket/5841
Merge pull request #1737 from retronym/ticket/6555

SI-6555 Better parameter name retention
Merge pull request #1738 from retronym/topic/dryer-crashes

DRYer crash reports.
SI-6685 fixes error handling in typedApply

When MissingClassTagError doesn't lead to an exception, but rather
silently sets an error, we need to bubble the resulting erroneous tree
up the responsibility chain instead of mindlessly typechecking this again.

This wasn't an issue before, because as far as I can guess the
aforementioned error setter was always throwing exceptions in the most
common usage scenarios (therefore the typecheck-again-fail-again
vicious loop wasn't triggered).
Test case for SI-6591
Attempt to fix

BUILD FAILED
Test suite finished with 18 cases failing:
/opt/git-repos/scala/test/files/run/showraw_tree_ultimate.scala [FAILED]
/opt/git-repos/scala/test/files/run/t5225_2.scala [FAILED]
/opt/git-repos/scala/test/files/run/showraw_tree_types_typed.scala [FAILED]
/opt/git-repos/scala/test/files/run/reify_csv.scala [FAILED]
/opt/git-repos/scala/test/files/run/t6223.scala [FAILED]
/opt/git-repos/scala/test/files/run/showraw_tree_kinds.scala [FAILED]
/opt/git-repos/scala/test/files/run/showraw_tree_ids.scala [FAILED]
/opt/git-repos/scala/test/files/run/freetypes_false_alarm1.scala [FAILED]
/opt/git-repos/scala/test/files/run/reify_ann2a.scala [FAILED]
/opt/git-repos/scala/test/files/run/showraw_tree_types_ids.scala [FAILED]
/opt/git-repos/scala/test/files/run/showraw_tree_types_untyped.scala [FAILED]
/opt/git-repos/scala/test/files/run/reify_newimpl_15.scala [FAILED]
/opt/git-repos/scala/test/files/run/reify_newimpl_30.scala [FAILED]
/opt/git-repos/scala/test/files/run/t2886.scala [FAILED]
/opt/git-repos/scala/test/files/run/reify_newimpl_29.scala [FAILED]
/opt/git-repos/scala/test/files/run/showraw_tree.scala [FAILED]
/opt/git-repos/scala/test/files/instrumented/inline-in-constructors [FAILED]
/opt/git-repos/scala/test/files/instrumented/InstrumentationTest.scala [FAILED]
Refine test for SI-6591
Final solution
Cleanup
Add meaningful names in test
Don't reify packages as Select