Don't naively derive types for the single method's signature
from the provided function's type, as it may be a subtype
of the method's MethodType.
Instead, once the sam class type is fully defined, determine
the sam's info as seen from the class's type, and use those
to generate the correct override.
```
scala> Arrays.stream(Array(1, 2, 3)).map(n => 2 * n + 1).average.ifPresent(println)
5.0
scala> IntStream.range(1, 4).forEach(println)
1
2
3
```
Also, minimal error reporting
Can't figure out how to do it properly, but some reporting
is better than crashing. Right? Test case that illustrates
necessity of the clumsy stop gap `if (block exists (_.isErroneous))`
enclosed as `sammy_error_exist_no_crash`
added TODO for repeated and by-name params

In 2.11.0-M8, the enclosed test issued the following feature
warning:
sandbox/t7750.scala:7: warning: the existential type LazyCombiner[_$1,_$2,_$3] forSome { type _$1; type _$2; type _$3 <: Growable[_$1] with Sizing }, which cannot be expressed by wildcards,
This went way in 2.11.0-RC1 after we turned off the problematic
attempt to infer existential bounds based on the bounds of the
corresponding type parameters.

Sealed abstract classes (like `List`) have a primary constructor, public
by default. It can never be called by external code but it shows up in
the scaladoc as a nice `new List()` construtor...
If a class is only abstract, the constructor is still useful because
people can subclass and call it. If it is only sealed (i.e. effectively final),
then it is the normal constructor of a final class. But sealed *and*
abstract makes documenting the constructor useless.
This should remove the misleading constructors of `List`, `Double`,
`Option` and others from the scaladoc.

This option has been allowed by the command line compiler since
ee706b8.
This commit allows use of this via Ant.
Note: we still don't exploit the features of classfile version 52,
but watch this space as we roll out method handle based closures
soon!

A classic mistake of discarding a non-trivial qualifier.
We actually should have fixed this before merging #3149, as it
was raised in review, but I suppose we got too caught up in the
difficulty of resolving the right overload of `Symbol_apply` that we
forgot.

If a class contains a double defintion of a method that overrides
an interface method, LUBs could run into a spot where filtering
overloaded alternatives to those that match the interface method
fails to resolve to a single overload, which crashes the compiler.
This commit uses `filter` rather than `suchThat` to avoid the crash.