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.

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.

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.

Add generic routing to get object's dynamic form entries.

Add support for complex options to support complex field rendering.

Conflicts:

	include/i18n/en_US/form.yaml
	include/staff/templates/dynamic-field-config.tmpl.php
	include/staff/ticket-view.inc.php
	include/staff/tickets.inc.php
	scp/js/scp.js

oops: Fix crash upgrading to c7c82835

oops: Fix crash rendering ticket view

oops: Fix crash posting response to ticket

oops: Fix refresh url after ticket reply post

orm: Locate annotations after the root model's fields

orm: Add PK field check for DISTINCT aggregate expressions

When using the DISTINCT option for aggregate expressions, ensure that when a
relationship is used in the aggregate, that a single field of the remote
model's primary key is used — rather than the foreign key, since it would
never have more than one unique value.

search: Re-implement basic ticket search

oops: Couple trivial changes

oops: Fix date formatting for PDF output

oops: Fix staff profile view and update

oops: Fix canned response listing

orm: Fix crash compiling WHERE IN (nested select)

nav: Move settings/email to email/settings

i18n: Make field visibility config translatable

oops: Fix crash adding field to custom form

forms: Fix `required` flag transfer to FormField

oops: Fix bad merge on new ticket by staff

forms: Show uneditable fields on new ticket by staff

oops: Fix bad merge on client ticket view

This will be used for greater flexibility in visibility and requirement
settings.

This will disable the ability for a user to close a ticket when they
have not filled out all of the required fields. Explains the problem to
the user trying to close and directs them to the edit page. Added some
functions to the $ticket class to make it easy to determine the missing
required fields.

Allow fields to be configured for view / edit / required for both agents and
end users. Fields can also be disabled now so that the field remains in the
form but is no longer displayed for new entries.

Allow tickets to be created without a subject — use the help topic full name
instead.

This is necessary so we can consolidate various settings and permissions
into one bit mask field.

Link entry and form and entryAnswer and field. This will alleviate extra
queries which would otherwise be required.

Previously, this was not ported properly now that multiple selections are
supported in the choice field and derivatives.