Rusty enums in DataValidation

[2ndDerivative]

Linking to issue #44 I made a first proposal to more closely align the abilities of Rusts type system to put away the mutable structure of Data Validation objects and make unnecessary changes to them impossible.

The "None"-Type of Data validation is not used since it has no representation (that I know of) in the Excel spreadsheet options, so I removed it. I fit all the possible enumerations and/or parallel options like the three tabs of the data validation settings (Settings, Input Message, Error Alert) into their respective part of the Data validation object and made the latter two unusable without setting an actual data validation setting (the same way Excel doesn't represent the other tabs when "Any" is chosen in the validation settings)

Arguments

the new API would have DataValidation take three arguments, two of which are optional:

• validation_type: This represents the Settings Tab and its options for each of the choices the user can make in that tab. As a structured enum the two-argument choices like Between take guarantueed two arguments and there can be no mixup for which field of the DataValidation Struct to use. If there are supposed to be defaults, we can add them via the Default trait
• input_message: This handles the second tab in the Data Validation tooltip from Excel. Since leaving the input message title empty in Excel is equivalent to not typing anything beforehand, the strings for title and message should probably not be Option<String>, but can just default to an empty string instead.
• error_alert: Same as input_message, but with an additional enum field to represent the ErrorAlert-Types like Stop and Warning

There still has to be some work done on making the different number options (equal, not equal, greater than, less than etc...) more usable, but it is already less messy than the mutable state weirdness that was used before, and which was not very "oxidized"

Please consider this proposal and tell me if you have any tips or feedback. I will continue some work on this to put it into better shape, but I'd love for the compiler to be able to help you in this better.

Another idea to make this less yanky with nested structs would be to pull the three DataValidation::new()-arguments directly into the data_validation_cell() and data_validation_range() functions

[2ndDerivative]

Is this going to be considered? And if not, is there a way I can make it acceptable? @informationsea

[informationsea]

Thank you for your pull request.