Collect frontend filter logic

[avaleske]

Refactor frontend filter logic so it's unified in one place.

As of #626 the concept of "what a filter is" is spread across multiple places:

• getComparisonForFilter()
• ListingFilterState
• FrontendListingFilterStateKeys
• ListingFilterKeys
• the encode/decode methods
• the various enums with options for the filters

To reduce the chance of hard-to-debug issues, we should refactor this logic into a ListingFilterStateManager class that can hold all this in one place.

It could an internal list of filters and their states, and have methods like

• getBackendFilterArray()
• getFrontendFilterQuerystring()
• a constructor that takes a frontend querystring as the parameter
• a constructor that returns a blank set of filters

Work toward this was completed by @elenm in #484, but was set aside so complexity around the interaction between the seniorHousing and communityType filters could be resolved independently.

[avaleske]

Adding this here so I can use it in the wiki, but this is the flow for the frontend filter state:

Note that the function names were just ideas, and the actual encode/decode functions are named differently.