Support ability to include attachments to FreeTextField.

This adds ability to delete properties on list deletion

Also make forms deleteble by marking them as deleted and hiding them from
the form listing. This ensures that custom data always has a link back to
the form.

These fields have been consolidated into the `flags` column.

Also, fix roundtrip encryption if the form name changes (which is based on a
user's session), and avoid saving a NULL value if the password is not
changed when a form is updated.

Add ability to extend Form
Support the concept of form ID
Clear/hide field errors on blur

This is necessary to allow objects to register data views on the fly.

This is a temporary patch for v1.9.7 -- develop-next already has a better
implementation.

Add ability to import and export list items

This feature addresses a major issue with the initial implementation of the
custom data system. The original system confused the usage of
database-backed field (dynamic-fields) and their corresponding
implementation. This created the need to crate awkward caching pieces to
ensure that validation errors and data was maintained. Furthermore, the
system confused the linking between form instances (dynamic-entry) and the
form used to represent that entry.

This patch addresses the confusion in two ways:

Dynamic form entries do not link directly to the dynamic form. Instead, the
::getForm() method returns something from the forms API directly.
Furthermore, the ::getFields() method does not return dynamic field
instances (database backed / designed fields). Instead, the actual
implementation of the fields from the forms API is retrieved. This allows
the fields to *always* be cached, which helps preserve data and validation
state.

Secondly, the dynamic form uses the same system, so that requests to turn a
dynamic form into a form (via ::getForm) will also result in the same
behavior, again, where the fields are represented as forms API fields rather
than the dynamic fields.

So going forward, the dynamic fields are *only* used to create corresponding
forms API field implementations. The are associated with the dynamic
counterparts as sparingly as possible.

When the user is not identified by the web interface, such as processing
email to tickets, attempt to locate and include the user filter information
when matching the filter to the new ticket data.

If an update to an object such as a ticket results in a corresponding update
to the CDATA table, and one or more of the fields have been deleted from the
ticket details form, then, avoid updating the CDATA table for those fields.

This fixes an issue where the CDATA table is dropped and recreated when
fields are added and removed from the form. The table will only contain
fields which are currently on the form when the table is created. Therefore,
deleted fields will never be on the CDATA table and will result in an SQL
error.

Support using value or abbrv. for choice/selection input fields.

For a yet unknown reason, the association between the field implementations
and the DynamicFormEntry object is not maintained from calls to
DynamicFormEntry::getFields().

This patch addresses the issue by always associating the "form" when
returning from ::getFields()

Preserve the fields indexed keys
Only sort the fields once, after adding missing fields

Reset field content when building a new form

Get all dynamic fields in DynamicFormEntry, not just fields with answers