hg: lambda/lambda/jdk: Remove FlatMapper and relevant flatMap variants; migrate to flatMap(e -> stream)

[Brian Goetz]

> The minimum I can't absolutely live without is a Turing machine, so don't mind
> me.  It's just that is it the 3rd time that something I really like is removed
> from the stream API.

I hope they weren't the only three things you liked.

For the record, the rationales are:

1.  Pluggable Op API.  It became apparent very early on that this was 
not going to converge within the timeframe needed, and that we were 
better off focusing on the parts that were going to converge.  Finishing 
this and including it in Java 9 is a high priority.  (By the way, had we 
committed to any of the forms from, say, more than two weeks ago, we 
would have nailed ourselves into a corner but good.  So this was clearly 
the right decision, it was just not ready to stabilize.)

2.  MapStream.  Again, trying to incorporate streams of different 
arities within the implementation and API was putting so much stress on 
the design that we were unable to move forward at an acceptable rate of 
progress.  By removing this as a requirement, we were able to progress 
much more rapidly on the stream APIs we do have.  After 8, we will look 
at whether it is possible to restore this functionality.

3.  FlatMapper.  We ran numerous focus groups and hack days, and the 
feedback was universal on "this isn't ready."  Better to leave it out 
than get it wrong.  As it stood, it was adding a great deal of API 
surface area for something few people could understand and even fewer 
could justify using.  If you're one of those few, congratulations -- 
you're not the target audience :)

Our goal has been to get what we deliver right, rather than deliver a 
bunch of stuff, some of which is right.  Sometimes that means a favorite 
feature is deemed not ready for prime time.