Standardize usage of AtomicInteger in Centroid

Hi,

We've been seeing the following stack trace come up periodically in production for a few months now:

```
java.lang.NullPointerException
at com.tdunning.math.stats.GroupTree.add(GroupTree.java:82)
at com.tdunning.math.stats.GroupTree.add(GroupTree.java:76)
at com.tdunning.math.stats.GroupTree.add(GroupTree.java:78)
... more of these two lines (76 and 78) ...
at com.tdunning.math.stats.TreeDigest.add(TreeDigest.java:121)
at com.tdunning.math.stats.AbstractTDigest.add(AbstractTDigest.java:130)
... our application code
```

We finally managed to get a dump of the full state of the GroupTree at the time one of these exceptions was thrown. Following the path indicated by the left/right (lines 76/78) pattern in the stack trace down to the leaf, we found a node with count=2, size=2, depth=1, and left=right=null. The count and size would have just been updated by lines 80-81, so at the time GroupTree#add was called they were both 1. This means the code would have gone through the `if (size == 1)` path in the preceding block:

```
int order = centroid.compareTo(leaf);
if (order < 0) {
    left = new GroupTree(centroid);
    right = new GroupTree(leaf);
} else if (order > 0) {
    left = new GroupTree(leaf);
    right = new GroupTree(centroid);
    leaf = centroid;
}
```

so if compareTo returned a non-zero value then left and right would have been non-null, which (contra-positively) implies that compareTo returned 0. This led to the supposition that possibly Centroids were being created with duplicate IDs.

Looking at the code, we noticed that incrementAndGet and getAndIncrement were both being used. This seems to expose the code to a race condition in which thread A calls incrementAndGet and gets the ID x, then thread B calls getAndIncrement and also gets the ID x. If we're unlucky enough to have both resulting Centroids have the same value, and then get merged, it could cause problems. We suspect (although admittedly lack definitive proof) that this is what's causing our NullPointerException.

Is there any reason for the discrepancy in AtomicInteger usage? If not, we'd love to try out this change and see if the errors go away.

Thanks!
Kevin