Template is used for canned auto-reply - triggered by filters.

This will remove the upper limit of BLOB sizes imposed by MySQL with the
max_allowed_packet setting completely.

This adds a new table %file_chunk which will contain the filedata in smaller
chunks (256kB). It also includes a new class, AttachmentChunkedData, which
will handle reading and writing the data, abstracting away the chunks.

This is done by migrating data from the %file table to the %file_chunk
table. One must beware that this must safely (the migration that is) plug
into the both the live osTicket developers as well as the users doing a full
upgrade from osTicket-1.6*. For this, the AttachmentFile::save method was
patched to use the new AttachmentChunkedData class to write the attachment
data to the database in chunks. That is, the migrater will use the new code
on the major upgrade and bypass the filedata column of the %file table
altogether. Therefore, the patch associated with this commit will not
migrate any data for the major upgrade.

For developers doing incremental upgrades, the patch included in this
commit will transfer the data from the %file data to the new %file_chunk
table by chunking it. As written, only the first 16MB of the attachment is
migrated. This could easily be adjusted, but it seems like a reasonable
limit for now.

Force target selection on filter form
Add minor code improvements

* Change table name from ost_email_filter* to ost_filter*
* Add patch for target field.

And rearrange files to work with the new layout for the finalized upgrader

Allow staff members the ability to select a default paper size which will be
used in printing tickets via PDF. In the future, this may be overridden per
ticket by a dialog box at print time.

Updating main.inc.php: File did not include a define statement for TICKET_EMAIL_INFO_TABLE used by include/class.ticket.php

Replace the ticket_{message,response,note} tables with a single
ticket_thread table that will contain data for all three current message
types. This simplifies much of the ticket thread code and paves the way for
other types of messages in the future.

Track assigned department, team, staff, and help topic when the ticket event
occurs. This will greatly help in correlation of various reports and queries

Also start plowing the way toward incremental database updates using a
patching technique. The hash of the main install SQL script for a respective
database will be used to track the signature of the database currently. The
signature will be stored in %config::schema_signature, and the main.inc.php
script can simply check the value in the schema against the value known to
the source code to be the signature the code expects. Should the two
signatures differ, patches in the setup/inc/sql/patches folder should exist
and be executed to assist in incrementally upgrading the database to the
new-current schema version.