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

Allow admins to offer a custom error message when using the text input for a
selection field.

Also, do not display this error message if the field was left blank.

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 a text box widget to selection field. It functions like typeahead and
drop down widgets with the exception that the user doesn't get the hint. This will
be useful when a list needs to be used to validate user's input.

Help topics can now specify one or more additional forms to be included on
the help topic and can also specify the sort order of those forms.
Furthermore, individual fields can be disabled per help topic, so that
unnecessary fields can be omitted when necessary, per help topic.

The disabled flag is recorded along side the field data so that the field
will not be accidentally added to the form later automatically. There is no
interface in this commit to enable a field which was disabled by the help
topic when ticket was created.