[TR #112] Use better systems for identifying matching errors

This switches the error matching strategy to not use stack traces at all, since these appear to be heavily dependent on where an exception was used. Instead, we do a small level of matching based on the exception's error message (this will have to be fine-tuned in the future, but that will require real data).

This also adds special casing, which allows otherwise identical exceptions to be differentiated based on a regex matching the message. This allows for separating unique cases (like when someone does "(1 2 3)" which is technically a ClassCastException but really needs to have a different message).

It also changes the testing strategy for the find function. It removes tests for the query functions since they were testing implementation rather than results (whenever I try to fix a bug or change the way they work it's needlessly breaking tests).

As a sort of replacement I added some tests using real-life data that show some examples of exceptions find should match, as well as some examples of what it shouldn't match. In the interest of brevity, the exception maps for these tests are stored in a separate file.

2nd WIP commit

WIP commit