Add the ability of revoking previous ticket state tracking events when new
events are logged for the same ticket. This will allow, for instance, the
ability to revert the 'closed' state of a ticket when the ticket is
reopened.

For statistics tracking, a user could configure whether or not the events
should be counted for each event tracked or just the non-annulled events.
For instance, if a ticket is closed and reopened several times, only the
very last closed event should count toward the statistics for the ticket.
Therefore, when a ticket is reopened, previous closed events should be
marked as annulled.

And correct several undefined function errors from several source files. So
while function names in PHP are considered case-insensitive, it still makes
sense to use consistent camel casing for both defining and calling methods.
The lint test searches the code base for method calls, and then searches the
code base again looking for a function definition matching the name of the
function invoked. It's not failsafe, because it doesn't detect the class
from which the method should belong, so it's likely to have false negatives.
Furthermore, it won't work well for PHP 5 where several classes are built
into PHP (and aren't searchable in the osTicket code base).

Remove the include/staff/api.inc.php as it no longer appears to be used (and
contains references to undefined methods).

Implement attachment migration for attachments
Add support for more information stored about the patches in the individual
patche files with a Javadoc style syntax

Add SQL patch file and update the main install SQL (MySQL) script to
transfer messages, responses, and notes into the new ticket_thread table.
For new installations, transfer is not necessary because there are no
messages

And make globbing platform independent, which also fixes an issue where not
all PHP files were scanned by the phplint tool for uninitialized variables

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.