Kfb/ranking ties

First pass at properly handling ties in the ranking. I don't think this is really ready to be merged just yet, but wanted to make it visible and get some feedback to keep moving forward on issue #16.

Some questions and thoughts.

1. I agree that consolidating the Curve constructors and build method would be helpful, though for now there are both primitive array and collection versions. Should we just take the plunge and have only primitive arrays for the Curve constructors and allow the Builder to convert from collections as necessary?
1. I'm currently ignoring any floating point comparison subtleties when detecting ties. Do we want to support an absolute or relative epsilon to detect effective ties even if the double representation is slightly different? My thought is no, and if ties are important, then double should not be the predicteds type and int or some other discrete type should be used.
1. The code to create the runLenghts array in Curve.Builder.build seems clunky right now. Maybe it is cleaner to not use the for each iterator and have a for loop over indices so the next tuple can be easily checked.
1. We should probably add some more tests. I have super simple tests of the basic functionality right now and am not sure what corner cases we need to consider.

Thoughts on all of this, @afbarnard?