Make a "FieldParser" object per jurisdiction, use it with JSON #286
Description
Right now we have a weird dichotomy where half of the parsing of a field is done right when the JSON filing object is submitted, and the other half is when we're preparing to submit the filing to Tyler. There is a good reason for this, as those are two separate parts of the system (one depends on what jurisdiction we're submitting something to), but the checks happening in different parts of the code / control flow is fairly confusing. It doesn't help that it makes it difficult to correctly keep track of the JSON attribute that's actually wrong (even though they're separate modules, there are hard coded assumptions between the two). Additionally, this will break when we introduce ECF5, which has different rules and codes for checking attributes.
I had a way to fix this in the ECF5 branch, and it was essential a parsing object would do the necessary checks for each field; each method is vet... (e.g. vetCaseCat, vetFilingTypes, vetEmail, vetPhoneNumber). In that original branch, it was still used in the Filing Review service, but it should be a part of the Docassemble / JSON parser, and would be just as beneficial. Then the filing review service could be more focused on submitting the actual filing. This is aiming towards "Parse don't validate as best we can (it's a compromise, as we can't dynamically restrict the values of each code).
Partially completed in https://github.com/SuffolkLITLab/EfileProxyServer/tree/hand_written_ecf5_prep, specifically the TylerCodesParser.