Future Filters Refactors

[avaleske]

As I was reviewing #1782 I was thinking about some additional changes to filters I'm thinking through:

1. I've been thinking about what it would look like to invert the filter parsing logic. Right now, in addFilters(), we iterate through the filter object/array, and handle each filter one at a time by adding the appropriate clause to the query. This works well because it allows the code to be generic, but it breaks down if filters need to be dependent on each other.

   For example, if we wanted to allow users to set both zip codes and neighborhoods, and search for listings in either rather than both, we'd need to handle that filter logic together, instead of one at a time as we do now.

   Instead, I wonder if it could make sense to pass the entire filters object into multiple filter handlers, such as addLocationFilters() and addRentFilters() that then look at the fields they care about and add the appropriate clauses to the query. This would be less generic, but would also let us remove the filterTypeToFieldMap and move the knowledge about which fields to check directly into the filter logic.

2. For many filters the comparison is implicit in the filter name. For example, for minBedrooms, it's obvious we should use a >= comparison. In our fork, we have a map in the frontend from filter key to comparison, so the rest of the frontend doesn't need to think about it. Wherever possible, moving the comparison logic to the backend so the frontend doesn't need to choose a comparison for obvious filters, would simplify the frontend.

@willrlin and @seanmalbert for visibility