Allows the client to be changed on a ticket. Previously, only the
information about the client associated with the ticket was editable. This
patch permits assigning a completely different user to the ticket.

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.

...

Process inline attachments in thread entry and support inline images in
piped emails

Support inline images across the system, with draft support

Migrate to a single attachment table
    That way we don't need a new table for everything we need to attach an
    inline image to (like a signature, for instance)

Add richtext support for internal notes

Implement images on site pages

* Image paste in Redactor
* Make non-local images optional
* Placeholder for non-local images
* Fix local image download hover
* Don't re-attach inline images

Protect againts cross-site request forgery attacks by requiring a special
form-field or header to be sent with requests that modify ticket system
data.

This meant a slight change to the AJAX ticket locking mechanism. It was
defined to lock with a GET request; however, GET requests are defined as
safe methods and should not modify backend data (such as a lock
acquisition). Therefore, the the lock acquire AJAX method was changed to
require a POST method.

Also remove old, no-longer-used staff panel include files

Most things work, still outstanding
  - the table needs to support filtering like the graphs,
  - the bootstrap.css file needs to be culled of what isn't used for now,
  - g.raphael needs to be re-minned after a issue is filed with g.raphael
    for the snapEnds() function not picking reasonable graph axes.
  - split dashboard.php into several smaller js, css, etc., respective files

Add support for aggregating data together and encoding it according to the
report AJAX specification for the reporting front end.