equality test can now compare columns with different names

[james-johnston-thumbtack]

resolves #1000

Problem

There is no way to compare two models using the equality test when the columns containing the same data have different column names. For example, if the first table has column biz_name and the second table has business_name, there is no way to compare them even if the data is the same.

Solution

The compare_columns now optionally accepts a list of two column names. This allows the column names to be different between base model and other model when comparing two columns.

The body of the macro is also refactored to make it more DRY, and reduce convoluting the different steps and capabilities.

1. First, we gather a set of numeric column names that we need to round. This is referenced later.

2. Next, we build two lists of column names that we want to compare: one list per model. If compare_columns was given, we build the lists from that. Otherwise, read column names from the first model, filter the excluded column names, and use the result for both models, as we did before this commit.

3. Now that we have lists of column names, we can build comma-separated lists for each model. At this point, we do the number rounding expression if the column name is found in the set from step 1.

Note this refactoring also cleans up some weird inconsistencies that resulted from duplication of logic. For example, suppose a model's column name was uppercase, and your database is case-sensitive. If you did not specify a "precision" argument, then you need to provide an upper-case "compare_columns" argument. However, if you did specify a "precision" argument, then the "compare-columns" argument was NOT case-sensitive. It's pretty unexpected to have the case sensitivity of one argument be dependent on a seemingly-unrelated argument.

Checklist

• This code is associated with an issue which has been triaged and accepted for development.
  • See Allow setting different compare_columns for each table/model in equality generic test #1000. The issue has not been triaged or accepted yet, but this was simple enough that I took a crack at creating a PR anyway.
• I have read the contributing guide and understand what's expected of me
• I have run this code in development and it appears to resolve the stated issue
  • I'm relying on the postgres integration tests to prove it works.
• This PR includes tests, or tests are not required/relevant for this PR
• I have updated the README.md (if applicable)