Rotation as a separate augmentation

[sparkfish]

Rotation as a separate augmentation

[jboarman]

I'd be fine with removing rotation entirely since imgaug and albumentations already offer that and they handle transforms of any associated masks, bounding boxes or keypoints. I assume we will have to adapt our code to support transforms of any such associated data, but we will need to do that at some point anyway.

[proofconstruction]

I agree that we should move rotation, out of the augmentation pipeline (this was my motivation for #20 ).

I'm in favor of further restricting the scope of our augmentations, where possible. When training models you'd have to restrict training data to reasonably-rotated images (+/- 15%?) anyway, so I don't see a need for us to apply arbitrary rotations by default.

Right now, if you wanted to rotate an image, you could use imgaug's Rotate class within a ForeignAugmentation wrapper from our utilities module. You should be able to do this in any layer of the pipeline.

Maybe a good compromise is to just change the default rotation behavior in the pipeline to not rotate, but still provide the option to do so by passing a rotation range like we already do. Then the feature is still available within our package, and someone who wanted to rotate their images wouldn't require additional dependencies on other augmentation libraries for this purpose.

[proofconstruction]

With this commit, rotation is now optional in the AugraphyPipeline.