Refactor Structure for Data Augmentation Methods
Is your feature request related to a problem? Please describe.
Currently, there are two ways to create augmentation techniques, as Ops or as Processor's. This causes inconsistency in for new users who want to create their own augmentation method. This Issue is mainly focused on addressing this issue by creating a more consistent user interface.
Describe the solution you'd like
The current solution for the problem is to convert all augmentation methods to Ops. The way to do this could be:
To create a two levels of Op, one which gives users complete freedom to define their augmentation methods along with how atomic operations like insert, delete, replace, etc work.
The second level can be one that restricts the freedom of users to implement these atomic operations, but increases ease of use by just requesting users to provide the logic for augmentation and leaving the implementation and validation to default methods.
By doing so, we can do away with Processors (which until now are mainly used to handle augmentations involving multiple Annotations) and maintain a consistent structure where all Augmentation methods are a type of Op.