fix line ending problems in FreezingArchRule

[codecholeric]

This addresses two problems:

1. if the rule description itself had different line separators than it was originally frozen with, TextBasedViolationStore would report contains(rule) == false and thus the result would be stored as new and the rule checking would succeed
2. if the single lines of the violation descriptions had a different line break than they were originally frozen with, these violations would all be removed as "solved" and the same violations with the different line break would be reported as new.

I think unfortunately the API is a little strange, i.e. that event.getDescriptionLines() would return lines that contain a line break (since what is the use to talk about a list of lines if the lines can contain line breaks and are thus multiple lines in themselves). But unfortunately this is not so easy to change, since the counting of violations is based on this at the moment. For example, that one long cycle report cycle detected ... \n dependencies of ... \n ... is counted as a single "description line". To change this we would have to adjust this mechanism and then optimally make it illegal to return strings with line breaks from event.getDescriptionLines(). But extending ConditionEvent and thus implementing this method is public API, so this might be a breaking change again. Altogether I decided to just fix this within FreezingArchRule for now and see, if there will be further problems with this in other areas.

To solve 1) I have adjusted TextBasedViolationStore to clean up line breaks from property names on save and load. I decided to add it to the file reading direction as well to a) also fix it for stores that have already saved Windows line breaks and b) support manual tinkering adding Windows line breaks in the future. Otherwise just storing them exclusively with \n as line separator would have probably been good enough. It would be better to solve 1) in a store independent way, so other store implementations would not have to deal with this problem, but unfortunately I could not find any way to do this, as long as the API is contains(ArchRule) and store(ArchRule, ...). We could maybe always have converted these rules via contains(rule.as(ensureUnixLineBreaks(rule.getDescription()))), but that also felt a little shady, and might be surprising in a custom store implementation to get rule.as(..) instead of the rule directly.

Problem 2) I have addressed within FreezingArchRule to make it independent of the concrete store implementation. I decided to put adapters on both "ends" of the rule, i.e. on the EvaluationResult producing the violations "lines" on the one side, and the violation store where we read violations from on the other side. That way comparisons should only happen between Unix line separators and violations should always be stored with Unix line breaks within the store.

Resolves: #458
Resolves: #508

[hankem]

LGTM!

I've played a bit with violation stores on Windows and Linux and think that it works as intended.