Review Request: CR#8001634 : Initial set of lambda functional interfaces

[Mike Duigou]

There's a large set of library changes that will be coming with Lambda. We're getting near the end of the runway and there's lots left to do so we want to start the process of getting some of the more stable pieces put back to the JDK8 repositories.  We've spent a some time slicing things into manageable chunks. This is the first bunch. We'd like to time-box this review at one week, since there are many more pieces to follow.

The first chunk is the basic set of functional interface types.  While this set is not complete, it is enough to be able to proceed on some other pieces.  This set contains no extension methods (we'll do those separately) and does not contain all the specializations we may eventually need.

The specification is limited; most of the interesting restrictions (side-effect-freedom, idempotency, stability) would really be imposed not by the SAM itself by by how the SAM is used in a calculation. However, some common doc for "how to write good SAMs" that we can stick in the package doc would be helpful. Suggestions welcome.

Elements of this naming scheme include:
- Each SAM type has a unique (arity, method name) pair.  This allows SAMs to implement other SAMs without collision.
- The argument lists are structured so that specializations act on the first argument(s), so IntMapper<T> is a specialization of Mapper<R,T>, and IntBinaryOperator is a specialization of BinaryOperator<T>.

In order to get the most useful feedback out of this review, we'd like to ask you follow the following guidelines for the review:

- We are time-boxed at one week. (until Nov. 7th)

- Please review the whole bunch in a single message if possible, rather than in bits and pieces.  It is far easier to extract useful feedback from one complete review than from a dozen partial ones.

- Please wait a few days before replying to other people's reviews! We want to keep the discussion on-topic to maximize the useful review content.  It is far too easy for the discussion to spiral off into minutia and lose sight of the goal -- which is to provide useful feedback on the API we're asking for feedback on.

http://cr.openjdk.java.net/~mduigou/8001634/2/webrev/