Interactive scaladoc: mark new typer run when done.

As of now, when backgroundCompile is in the same typer run as
scaladoc-fetching logic, typer is confused with stale symbols.
SI-7355 Handle spaces in paths in Windows batch files.

Changed "%1%" and %2% to "%~1" and %~2 to allow spaces
in paths by surrounding quotes according to advice at:

  http://stackoverflow.com/questions/473117/pass-path-with-spaces-as-parameter-to-bat-file
  http://ss64.com/nt/syntax-args.html
SI-6675 Avoid spurious warning about pattern bind arity.

In 692372ce, we added a warning (under -Xlint) when binding
a `TupleN` in to a single pattern binder, which wasn't allowed
before 2.10.0, and more often than not represents a bug.

However, that warning overstretched, and warned even when
using a Tuple Pattern to bind to the elements of such a value.

This commit checks for this case, and avoids the spurious warnings.

A new test case is added for this case to go with the existing
test for SI-6675:

    $ ./tools/partest-ack 6675
    % tests-with-matching-paths      ...  3
    % tests-with-matching-code       ...  2
    # 3 tests to run.
    test/partest --show-diff --show-log                  \
      test/files/neg/t6675-old-patmat.scala              \
      test/files/neg/t6675.scala                         \
      test/files/pos/t6675.scala                         \
      ""

    Testing individual files
    testing: [...]/files/pos/t6675.scala                                  [  OK  ]

    Testing individual files
    testing: [...]/files/neg/t6675-old-patmat.scala                       [  OK  ]
    testing: [...]/files/neg/t6675.scala                                  [  OK  ]
    All of 3 tests were successful (elapsed time: 00:00:03)
SI-6943 warn on value class miscomparison.

There's a very dangerous situation running around when you
combine universal equality with value classes:

  // All over your code
  val x = "abc"
  if (x == "abc") ...

  // Hey let's make x a value class
  val x = new ValueClass("abc")
  // Uh-oh

There was until now no warning when comparing a value class
with something else. Now there is.
Update links to old website, in preparation for launch.

Removed the contact form, since it's redundant with mailing lists and
issue tracker.
Corrects link in README.rst
[nomaster] SI-5353 prohibits Array()

TODO: I'm about to fix SI-5923, and that fix is going to uncover SI-5353
(see more information here: https://github.com/scala/scala/pull/2464).

Since the fix to SI-5353 is going to bring binary incompatibilities,
we cannot include it into 2.10.x, but we want to fix SI-5923 in 2.10.2.

Therefore we decided to emulate the portion of SI-5923 that used to mask
SI-5353. That's only a temporary hack targeted at 2.10.x. There's no
reason for this code to be merged into master.
[nomaster] SI-5923 instantiate targs in deferred macro applications

Amazingly enough, the fix for the "macro not expanded" problem was super
easy. (And I remember spending a day or two trying to find a quick fix
somewhen around Scala Days 2012!)

The problem was in the implementation of the macro expansion trigger,
which was buried in a chain of if-elif-elif in `adapt`. This meant that macro
expansion was mutually exclusive with a lot of important adaptations, e.g.
with `instantiate`.

More precisely, if an expandee contains an undetparam, its expansion
should be delayed until all its undetparams are inferred and then retried
later. Sometimes such inference can only happen upon a call to instantiate
in one of the elif's coming after the macro expansion elif. However this
elif would never be called for expandees, because control flow would always
enter the macro expansion branch preceding the inference branch.

Therefore `macroExpand` now takes the matters in its own hands,
calling `instantiate` if the expansion has been delayed and we're not in
POLYmode (see a detailed explanation in a comment to `macroExpand`).

Consequences of this fix are vast. First of all, we can get rid of the
"type parameter must be specified" hack. Secondly and most importantly,
we can now remove the `materializeImplicit` method from Implicits and
rely on implicit macros to materialize tags for us. (This is a tricky
change, and I'll do it later after we merge as much of my pending work
as possible). Finally, we learn that the current scheme of interaction
between macros, type inference and implicits is, in principle, sound!

NOTE: This patch is a second take on fixing implicit macros, with the first
one being a backport from macro paradise merged into master in January 2013.
The original fix had an unfortunate error so I had to refine the approach here.
This means that it's not possible to directly merge this commit into master,
so I'm marking it as [nomaster] and will submit a separate pull request
targetting master later on.
[nomaster] macroExpandAll is now triggered in all invocations of typed

macroExpandAll is the key player in the mechanism of expanding macros after
their type arguments have been inferred. (Macro applications that contain
yet uninferred type arguments don't get expanded and are delayed until
the targs are inferred. Therefore later on we need to trigger those delayed
expansions manually, which is done by macroExpandAll).

Previously macroExpandAll was only called from a few selected places in
the typechecker, but that's quite risky, since typer evolves, and who knows
when this scheme breaks.

To make things more robust, I'm now calling macroExpandAll in the epilogue
of every single call to `typed`. Don't worry - this shouldn't impose
noticeable performance penalties, since the call is guarded by a branch
upon a plain boolean field.

NOTE: This patch is a second take on fixing implicit macros, with the first
one being a backport from macro paradise merged into master in January 2013.
The original fix had an unfortunate error so I had to refine the approach here.
This means that it's not possible to directly merge this commit into master,
so I'm marking it as [nomaster] and will submit a separate pull request
targetting master later on.
[nomaster] SI-5923 a simple alternative to onInfer

This fix provides implicit macros with an ability to affect type inference
in a more or less sane manner. That's crucial for materialization of
multi-parametric type class instances (e.g. Iso's from shapeless).
Details of the technique can be found in comments.

The changes introduced here are good from the conceptual point of view,
but are sub-standard as far as clarity and cleanliness are concerned.
As the latest advances in implicit macrology show, there's no need for
an elaborate mechanism of keeping track of undetparams in Macros.scala,
therefore we should really clean that stuff out. However, this is 2.10.x,
and I want to minimize the surface of code changes in order to make sure
I don't break anything.

Having said all that, I'd like to note that this commit is only targeted
at 2.10.x. There's no reason for it to be merged into master.