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.

There was a slight issue when transitioning from a short answer field to a
drop-down field, and when the CDATA table is dropped and rebuilt.

Prior to osTicket v1.9.4, drop down lists only allowed for a single entry.
After upgrading to 1.9.4 the database data for drop downs changed to allow
for multiple entries. However, the old data format was not properly handled
by the SelectionField::to_php() method which handled interpreting and
upgrading the database data.

The real bug was setting the source of the ticket form — not the fallback to
the form entry source.  Falling back breaks edits.

This patch fixes a small glitch where validation might be bypassed for
fields for agents. Previously there was a glitch where required fields would
have their validation errors ignored.

When processing the value of a DynamicFormEntryAnswer, if there is no
database-backed, value, then use the value of the associated field.

This allows administrators to select a default value for selection fields
deriving from Custom Lists. This has been implemented on the ChoiceField,
but was forgotten on the SelectionField

  * Use the title of "Information" with internal tag of "info"
  * Add "Visibility" column to UI and retire "Required" and "Internal"
    columns
  * Add visibility selection to new fields and show visibility to the user
    information fields when displayed on the ticket details form
  * Make the visibility settings translatable
  * Use constants internally for visibility configuration detection
  * Use a larger input when managing the information HTML content
  * Fix validation errors for new fields
    * Enforce new field name uniqueness
    * Enforce new field name character validation

Hide multi selection option for typeahead selections

This will be useful for maintaining arbitrary list of items. ListObject
should be used in the place of ArrayObject