Anomaly changes

Follow up to #956 by @breznak 

CC @subutai @oxtopus @rhyolight 

WIP!

- [ ] - The current method for specifying the type of anomaly you want doesn't let a 3rd party create their own. Can we change this to a base class defining the interface and then a set of subclasses? Separating into separate classes also makes each method easier to understand and test since you don't have the sliding window logic, etc all in the same class.
- [X] - The anomaly class supports taking either current predicted columns or previously predicted columns. I don't see any reason to have the class support both. Rather than duplicating the previously predicted state I think the new class should take the previously predicted only. (d9ecf61)
- [X] - I don't think we use the KNNAnomalyClassifierRegion but the change there added state to the class with no benefit. It should just use computeRawAnomalyScore. (d5f383b)

Other changes:

- Clean ups (1ad37c0, c8f2af3)
While this is correct, the idea was to unify the method for accessing anomaly in one class, these test change it back, so the only code that tests the "new" anomaly is the one cumulative test.