bugs: Fix collaborators lookup

Reviewed-By: Jared Hancock <jared@osticket.com>

lists: Update list management page

Reviewed-By: Peter Rotich <peter@osticket.com>

Conflicts:
	include/staff/tickets.inc.php

bugs: Fix  help topic create + forms

Reviewed-By: Jared Hancock <jared@osticket.com>

topic: forms: Hide forms with no visible fields

Upgrader bug fixes

Reviewed-By: Jared Hancock <jared@osticket.com>

upgrader: Log SQL errors

Reviewed-By: Jared Hancock <jared@osticket.com>

Conflicts:
	assets/default/css/theme.css
	include/client/tickets.inc.php
	include/staff/templates/tickets.tmpl.php
	include/staff/ticket-view.inc.php
	include/staff/tickets.inc.php
	scp/css/scp.css

Conflicts:
	include/class.list.php

filter: Fix filtering by list item properties

Reviewed-By: Peter Rotich <peter@osticket.com>

Collaborators for threads, lock as a utility

Reviewed-By: Peter Rotich <peter@osticket.com>

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.

login: Require CSRF token to login

Reviewed-By: Peter Rotich <peter@osticket.com>

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.