Overload resolution simplification

[Brian Goetz]

>> What makes you think the goal is encouraging explicit lambdas?
>
> Overloads are part of the java legacy. Ignoring them and you will see
> enterprise guidelines saying that only explicit lambdas should be used.
> Otherwise, it will break when someone will add an overload.

Overloads are part of the legacy, but the number of genuine SAM-SAM 
conflicts with existing APIs are pretty small -- I think 
Executor.submit() is the #1 case, and there are only a handful of others.

What we're trying to discourage is new, designed-for-lambdas APIs from 
getting out of hand with overloads.  Overloading and type inference work 
against each other, so if you want to design an API for type inference, 
you need to dial back on the overloading.  (Which we've gradually done 
throughout the course of designing the java.util.stream API, for a host 
of reasons.)

So:
  - For new APIs, go easier on the overloading when there are possible 
SAM conflicts;
  - For old APIs that have such conflicts, go explicit.

Maurizio's latest patch also includes a lint warning for overloads that 
are asking for trouble, so hopefully API designers will have a way of 
catching those early.