Fixes #374

Displaying field values on various pages and dialogs could result in cross
site scripting exploits.

Fixes osTicket/osTicket-1.8#296

The check in DynamicFormEntry::getAnswers() will use the cached _values
array if it is not set to null. Previously, the ::save() method would set it
to an empty array.

Again, fix issue where multiple mails fetched in the same fetch run will set
the user of each of the mails to the user of the first email fetched.

The previous patch neglected to pass the new $cache argument through the
inherited UserForm::getFields() function.

If two emails were fetched in the same timeframe, they may both be assigned
to the same user account.

Add update routine
Add updated date getter

without required, internal contact field

Fixes osTicket/osTicket-1.8#203

  * Require a label on form fields
  * Require variable name to be unique per form
  * Fixup duplicate phone numbers on upgrade

Fixes a case where multiple tickets are created in one request (such as a
cron job triggering multiple email fetches). The TicketForm::getInstance()
called in Ticket::create() used a singleton pattern to retrieve a cached
instance of the TicketForm. In the case of ticket creation, each ticket
needs a new TicketForm entry instance.

Fixes #111

The typeahead for user email address was dropped somewhere along the way

Fixes #77

If a form field is required, then a name will be necessary in order to plumb
up the API.

Previously, clients would not be able to create tickets if an internal,
required field existed on any of the forms presented to the user. Instead,
they would be stuck at permanent validation failure because there was no
data for a required field not shown.

This patch adds a feature to the form and dynamicFormEntry objects'
isValid() method to receive a callable to filter which fields' errors should
be added to the form's errors list. This allows for more complex validation
where in some cases, validation errors should not be considered on some
fields.

Fixes #45

Which will help fight off spammers. This should be coupled with logic that
will add some enticing fields, like 'email' and 'name' to invite bot input.
Then, on the form processing side, a spam submission can be detected and
handled differently from human submissions. This should lessen reliance on
CAPTCHA only as spam detection.

Previously, the value of the selection was lost in the request and, if the
form field was marked as required, then a ticket could never be submitted.

Including adding support to the TCL uninitialized variable reader to ignore
class-static variable access as well as detect inline functions and their
closure arguments.

Fixup several minor bugs concerning initial experience

Moved to an initial form which specifies the ticket's priority and issue and
changed the rendering to render things properly. Now the user can decide
where priority shows on the client side, and the priority privacy setting is
placed in the dynamic form wizard.

The standard form is added to every ticket without option. Extra forms can
be defined and associated with help topics which can additionally be added
to tickets upon creation. This allows for standardization of the dynamic
data location for searches and filtering.

Implemented advanced search for dynamic data. Along with reinstating the
basic ticket search on keywords

Implemented ticket filtering on dynamic data for both keyword searches as
well as searches for special fields (drop-down lists, etc.)

Phone number for users is now completely optional

This moves client information like name and email address out of the general
dynamic forms data for a ticket. It really paves the way for the first-class
user of the future.

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.

Use an internal hash table of join information to prevent multiple joins
over the same path. Also use table aliases in order to support self joins or
otherwise multiple joins to the same table using different paths.

*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.