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

Introduce the concept of role-based access for agents.

First implementation of built-in custom list

  * Upgrade to Redactor 9.1.7
  * Use a (x) icon from font-awesome for the dialog

Previously, form sections were grouped into form sets for reusability. This
patch drops the form sets and makes form sections the new "forms".
Eventually a section-header field will be added that technically does not
add any dynamic data to the form, but allows for the same feature as having
a form set with multiple sections.

*This is a major redesign / rework of the osTicket base*

This patch drops the concept of static ticket metadata and allows for an
admin-configurable arbitrary data that is attachable to tickets

The system is architected such that the base osTicket install now comes with
a "default" form that has fields for subject, name, email, and phone number.
This form is editable to allow for the addition of arbitrary other fields;
however, the basic fields must remain in order to be associated with a
help-topic and attached to a ticket.

This concept can be expanded to allow for arbitrary data associated with
registered clients or ticket thread items.

Forms are comprised of sections. Sections have a title and instructions
properties and a list of fields. Fields have various implementations to
represent different data such as text, long answer, phone number, datetime,
yes/no, and selections, and are configurable to define the look and feel and
interpretation of the respective form field.

Dropdown lists are represented as "Dynamic Lists", which are
admin-configurable lists of items. Dropdowns can be optionally represented
as Bootstrap typeahead fields.

This also adds the start of a simple ORM which will hopefully be expanded in
the future to support multiple database platforms. Currently, only MySQL is
implemented.