Create a distinction between file validation and logical data validation

[upstreammuse]

There should be a validation layer between reading the file (syntax validation) and semantic validation. The semantic validation is necessary because a human made the input file, and should still be used as part of reading a gui-saved file. However, the semantic validation isn't related to processing errors, so it could be in a layer before the real processing starts. Essentially there should be a distinction between the kind of validation that needs to run because a human wrote an input file that could be internally inconsistent from the kind of validation that always needs to run to check for balance issues, savings issues, and logical things that don't come from bad file input.

[upstreammuse]

With the move to a GUI version, this issue is basically moot. From here out, file errors need to be one of two cases:

1. Unresolvable syntax error in the file. Typos, spacing issues, etc. that the program simply cannot overcome without second-guessing what the user might have written. These errors should cause "unable to read file, line XXXXXX" error messages to the user to assist with fixing the file.
2. Logical issues in the file content. Incorrect balances, date mismatches, etc. that the program can possibly work around with some careful processing. These errors should ideally not prevent loading a file, but should instead cause the data to be flagged in places where it is inconsistent or incorrect.

It's worth pointing out that there are almost certainly cases where type (2) errors are being treated as type (1) errors, but this is honestly not a high priority to fix right now, since a file-manipulating user is expected to have a workflow that revolves around updating the file directly based on feedback from the program (in which case the file read error popups do the job), and a GUI user won't get into these problems to begin with.