Add sorted take optimizations

closes #880

Should be good enough, I think.
@avibryant a couple of problems here:

1) If there is no ordering defined, it is janky or broken to use the heap approach (I could define a fake ordering on the hashcodes, for instance).
2) If we don't do the above, we need a new monoid that that takes the left most K things. I think that is a monoid (but I didn't prove it recently).
3) At the end of the above, we still don't get the tuning on the constant, which is a much bigger issue in my view.

So, Avi, can you make a stronger case for bufferedTake to justify the expense in effort of coding, especially given, in my view, the main issue is what the threshold should be in the sorted case (distributed take without sorting is both rare, and somewhat ill-defined).