MySql 5.6 and MariaDB 10 will return affected_rows == 0 if updating a row to
its current values. Therefore, if an object is "edited", but none of the
CDATA is modified, then the CDATA table might be dropped and rebuilt.

Use `if not exists` in the create statement for the %cdata table so that, in
some race conditions, a MySQL slave would not be crashed because of an
already-existing table.

Also fix several javascript errors on ticket edit

This will allow for self filtering form based on options
Delegate form validation to Form instead of DynamicFormEntry

* Preserve external storage flag on field configuration
* User gridlayout to render task's forms
* Use new roles for task's nav

Credit: Jared Hancock <jared@osticket.com>

Allow fields without data to do house-cleaning on deletion.

This fixes a strange issue where the first field of a custom form stapled to
a ticket is not populated with data sourced from the API.

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.