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.

Also fix a crash when re-rendering the new ticket by staff page after a
validation error.

This will allow for more complex widgets to be added as plugins which
include css and javascript media files without manually adding header or
footer lines.

This includes the initial concept of pluggable authentication along with the
initial concept for a plugin management system.

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.

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.

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