Add ticket status properties field before loading init data.

This will allow administrator to indicate if end users are allowed to reopen
tickets in a particular closed status.

This is necessary to avoid confusion vs. closed state.

Make table prefix consistent

And fixup the migration patch

Implement the logic to set status

Help topics and filters can override the default status

Changed Resolved to resolved state
Add ability to get statuses by states

DynamicList initial data

Add TicketStatus class and ticket_status table

Multilanguage Support via gettext

- added gettext encapsulations to all texts i thought necessary
- added fallback function for the case that the gettext extension isn't loaded
- added browser language detection
- added gettext to the list of optional extensions in setup
- rewritten some of the texts to use sprintf instead of appending strings
- added german translation file
- removed mark_overdue-confirm from cannedresponses.inc.php

extend multi language support and a fex fixes

- Better detection of translation files
- Added functionality to redirect language codes (see redirecting
language codes)
- Ticket Status can be translated
- The Datepicker can be translated
- Extended functionality of 'testlang.php' to show what language code is
used to translate

Forgotten to apply a patch from RC5 to RC6

- Forgotten to change $var to $vars in line 380 of class.mailfetch.php
- Removed unneeded comment

Added php_gettext as primary translation engine

- Added php_gettext support (thanks to Danilo Segan and Steven
Armstrong)
- php_gettext is now the primary translation engine
- Extended language detection functionality

Add error/misconfiguration checks and fix undefined variables

Change v1.8.2 to v1.9.0
Drop help tips for list properties

Previously we required an account to associate a user to an organization.

This will make upgrades from osTicket < 1.8.0 substantially faster and more
reliable, considering that the previous ticket threads will not need to be
explicitly converted to html.

There was a major goof for osTicket 1.8.0 where the installer created a
`form_id` column in the `%filter` table; however, the upgrader neglected to
add the column. Therefore, users who have upgraded from a version previous
to 1.8.0 will not have the `form_id` column in their database whereas users
who installed osTicket >= v1.8.0 and upgraded will have the column. Since
MySQL has no concept of `ADD IF NOT EXISTS`, this dynamic query will
assist with adding the column if it doesn't exist.

Thanks, http://stackoverflow.com/a/16405301/1025836

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.

This is necessary to avoid illegal mix of collations error during upgrade
for MySQL with strict language setting.

Because the file type normally defaults to the system default (for fetched
emails at least), the backend char was not saved, because the file type char
was left at the system default. Therefore, if a file is saved to a backend
other than the default (in the database), the data will likely be saved to
the backend, but the file metadata will reflect the incorrect backend.

The only reason the file type char was not defaulted in the
AttachmentFile::save() method was for the migration process from osTicet 1.6
to osTicket 1.7. This is mitigated by passing `false` specifically from the
migration task.

Since otherwise the file type char is now set, the backend char is now saved
with the file metadata.

They are only available for tickets arriving via the email channel. All
other channel (including email) use the new ticket form to record the
subject and body, which are mapped to the 'Issue Summary' and 'Issue
Details' fields respectively

Structure the drop-down list for the `what` column to be future-minded
concerning custom user data matching.