This patch includes a slight database migration, and adjusts the
functionality of a few core components.

  * Move collaborators from the ticket to the thread.
    This concept allows collaborators on any object which has a thread,
    including tasks.

  * Add flags to the thread entry
    This will allow flagging thread entries for different purposes.
    Initially this can be used to flag the original message of a thread in
    case a ticket / thread is created without an initial message.

  * Lock becomes more of a utility
    The lock is now disconnected from the ticket and is a separate utility.
    Separately, the ticket and task objects can have a reference to a lock
    object. Furthermore, when submitting some activities to tickets, the
    lock is verified to be owned by the respective agent, and the lock code
    must match a current lock code. The code is rotated on each acquire()
    call to guard against double submissions.

  * Collaborator is an ORM model
    The TicketUser class is broken up now so that the collaborator instance
    can exist apart from a ticket. Email message ids are now generated for
    collaborators without respect for a ticket so that collaborators can be
    properly supported on any thread.

This patch fixes a vulnerable scenario, where sequential login attempts can
be made without an existing session, and without a valid CSRF token. This
scenario lends itself well for brute force password attempts, because
attackers can avoid using a session and still send requests to determine if
a set of credentials are valid. This vector also avoids the authentication
lockout mechanism, because it requires an ongoing session to shutdown the
requests.

This patch addresses the issue by requiring a session and a valid CSRF token
generated by the server and placed in the session to be submitted with the
credentials. Therefore, an existing session and a Cookie header are required
to process a login attempt. Secondly, the CSRF token will be changed on the
server after each login processed. Therefore, for each session, a subsequent
GET request would be necessary before submitting another login attempt.

This would be required for new ticket auto-responses to tickets created
without an initial message.

Since tickets can be created without a message now, the emailing system
should also identify the thread the message is associated with, so that a
returning email can be associated with the ticket or task's thread in the
event that it was created without an initial message.

References:
https://bugs.php.net/bug.php?id=43200
http://stackoverflow.com/a/22521203

Also try harder to send a relevant In-Reply-To and References header back
to the client with the email message.

This patch suggests a change to the message-id creation process that
includes stamping the receiving user-id (staff or client) along with the
thread-id of the originating notice. This allows detection of threading if
the clinically brain-dead mail client drops all the other header detection
mechanisms, including the tag placed in the email body, on response.

This patch works for both client and agent communication.

This patch converts the central file and threading classes over to use the
ORM.