This will help if the user has "Browser Preference" selected as the
preferred language. When email correspondence needs to be sent to the user,
the browser_lang extra attribute can be used as a backup to to the user's
language preference in the event that the language preference is set to auto
(Browser Preference).

Determine and set a reasonable max file size on install
Remove file extension restrictions - transition to mime types

This patch also makes a slight edit to mPDF to allow better detection of
substitions in characters, as the DejaVu fonts shipped do not support Thai
glyphs.

If there is a problem installing some of the items with the system, try not
to crash simply because the error is passed into another ::create()
function.

DynamicList initial data

The software defines at least three contexts for the phrase "Open"

  * The name of a ticket queue (Open tickets)
  * A status of a ticket (Open / Closed)
  * An action to be performed (Open a ticket)

References:
(Crowdin login required)
http://i18n.osticket.com/translate/osticket-official/148/enus-de#2915

Add TicketStatus class and ticket_status table

Make the organization page happy!

Arrange templates in a group by their respective use in the system:

  * System Management Templates
  * Staff Ticket Templates (Alerts and Notices)
  * End-User Ticket Templates (Autoresponder)

This provides an interface to sort the templates and make them easier to
find and provides a nice place for new templates to be added without making
it increasingly more difficult to locate templates in the list.

This patch also fixes the missing templates in the drop-down list when
editing an implemented template.

And install initial data in target language. Also configure help tip
popovers to be in the configured, default system language.

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.