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 (until Nov. 7th), 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.

Doug has also suggested we have some sort of regularized, low-level naming scheme.  There's nothing in this bunch that is inconsistent with that; if we had such a thing, the nominal SAMs here could easily implement the horribly named low-level versions.  We're still thinking about how that might fit in, so while that's not directly reflected here, it hasn't been forgotten.

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>.
- Multi-arg versions use prefix BiXxx, TriXxx, as suggested by Doug. However, the "natural" arity varies.  No good two or three letter prefix for zero or one comes to mind (e.g., UnaryFactory<T> or NilaryBlock (though that's the same as Runnable.)  So that could be improved.

Please review and comment.

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