Use native field API to generate filters in redhen_filter_form

Problem/Motivation

The redhen filter form used to filter entity lists includes filters for a certain subset field values. Custom code is used to generate the filters, with a generic textfield default supplemented by special handling for date fields and fields configured to use select lists.

While this approach allows some basic filtering, it has several limitations:

• Only a single column is allowed per field, preventing filtering by multiple column fields.
• Only the generic 'value' and the taxonomy term reference 'tid' columns are supported.
• The text input in many cases makes input difficult. For example, date fields would be more easily handled with multiple selects or a Javascript date picker.
• Selects may be broken in cases where their values are not loaded from an allowed values array. For example, taxonomy term selects are broken (with the exception of note_type selects, which are handled by code in an alter hook implementation in redhen_note).
• Handling of additional field types may require extensive custom coding.

Proposed resolution

Replace the current custom code with code using the field API's built-in form element generation. That way we'll get the specific input widgets for each field. For example, for address fields, we'll get the full address element (country, province, city, street, etc.) complete with its Ajax behaviour when the country is switched.

• In redhen_filter_form(), call field_default_form() to generate form elements for fields based on their configured widgets. Manipulate the widget settings to prevent any field from being required. This usage parallels what's done in the field configuration screen when generating a form element for setting the field's default value.
• In redhen_filter_query(), process input for all valid columns.
• For date type fields, invoke the to date behaviour to have two date inputs and process accordingly.

Remaining tasks

• Redhen email fields are not working as expected. They lack a title and formatting. Troubleshoot.
• Ensure that all filters default to a state where they are not active. Currently, for example, date fields use their widget's configured default. If that's 'now', they are in effect not optional, since leaving them as is will produce filtering. Specific subtasks:
  • Set defaults for date and other elements to zero length strings where available.
  • Determine what to do about checkbox elements, especially boolean ones, which can't effectively be inactive. Simply remove them? Convert them to radios with a skip option?
  • Handle country field in address fields. Add a zero length string select option?
• Some field types won't work by default. For example, float fields will never be matched and, like date fields, would require a range. Geographic fields might require proximity handling for point data or other special handling for lines or polygons. Do we explicitly limit support to fields with known support?

User interface changes

Filter form elements use native field input widgets.

API changes

n/a