Initial concept for user directory

If the help desk administrator has enabled requirement of login to create
new tickets and has also disabled account registration, then new tickets
cannot be created via the web portal.

Client accounts now that the user is verified either via staff or the
client's email mailbox, there's a much lower risk to showing a verified user
other tickets and virtually no reason that an administrator should have to
turn the feature on.

Add client registration methods and login required checkbox

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

And extend the information to email templates

Add information about current software versions, server software, php
extensions loaded, and database space usage.

In the future, this will offer a nice place to add an import/export button
for data backup and restore, announcements, and more

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.

 - Supported pages: landing, offline, thank-you and other

 * Collapse Department into Staff tab.
 * Add a new 'Manage' tab - home for managing items, lists..etc.
 * Collapse Help Topics into Manage tab.
 * Move SLA and API from Settings to Manage tab.

This will help distinguish between the knowledgebase part which encompasses
FAQ's and canned responses, and the FAQ part which contains the articles
detailing frequently-asked-questions.

changing ticket create/status bottons on client landing page, redoing navbar shadow with css, adding kb icons