[backport] Disabled SI-6987.

It causes spurious failures - a typical example:

[partest] testing: [...]/files/run/t6987.scala                                  [FAILED]
[partest] did not get the string expected, full results were:
[partest] Fast Scala compiler version 2.11.0-20130126-111937-f01e001c77 -- Copyright 2002-2013, LAMP/EPFL
[partest] [Given arguments: -shutdown -verbose]
[partest] [Transformed arguments: -shutdown -verbose -current-dir /localhome/jenkins/b/workspace/scala-checkin-manual]
[partest] [VM arguments: ]
[partest] java.net.ConnectException: Connection refused
[partest] [Connecting to compilation daemon at port 32808 failed; re-trying...]
[partest] [No compilation server running.]
[partest]
(cherry picked from commit 53d5df5c1d52b941732c243159de4f44456f03b4)
Merge pull request #2010 from retronym/backport/1985

[backport] Disabled SI-6987.
Test case for SI-7009.

The next commit fixes the problem itself and it's easier to see
in diff what's being fixed exactly.
SI-7009: `@throws` annotation synthesized incorrectly

The 990b3c7 made `scala.throws` annotation polymorphic but forgot to
adapt compiler code that synthesizes it, e.g. when parsing class files.

The consequence was that we would get non-deterministically either
`scala.throws` or `scala.throws[T]` as a type for synthesized annotation.
The reason is that `Symbol.addAnnotation` would call `tpe` method which
does not initialization of symbol so type parameters list would not be
determined correctly. Only if info of that symbol was forced for other
reason we would get `scala.throws[T]`. That non-deterministic behavior
was observed in sbt's incremental compiler.

Another problem we have is that Scala allows polymorphic exceptions
so in ClassfileParser we could synthesize `@throws` annotation with
wrong (polymorphic) type applied. In such case the best we can do
is to convert such type to monomorphic one by introducing existentials.

Here's list of changes this commit introduces:
  * The `Symbol.addAnnotation` that takes symbol as argument asserts
    that the type represented by that symbol is monomorphic (disabled
    due to cycles; see comments in the code)
  * Introduce `Symbol.addAnnotation` overload that allows us to pass
    an applied type
  * Change all places where polymorphic annotations are synthesized
    to pass an applied type
  * Handle polymorphic exception types in
    `ClassfileParser.parseExceptions`

Fixes SI-7009.