This changes the queue counts shown at the bottom of the page to no longer be
calculated using the SQL_CALC_FOUND_ROWS method of MySQL. Such is very slow for
large recordsets. Instead, a rough count is computed based on the total number of
tickets in the queue without respect for staff access. This is the fastest way to
get a maximum number of possible tickets to be shown. The pagenation interface
should be changed to show only NEXT and PREVIOUS pages where the rough estimate can
be used to provide a rough idea of whether or not another page of data would be
available.

Furthermore, if APCu is available, the rough count is stashed and kept between
requests so that the rough counts do not need to be re-tallied until they would
change from a ticket state change.

Another optimization might be to increment and decrement the queue rough counts when
tickets are created or change states. In such a case, it could be identified which
queues the old ticket would have been (and decrement the count) and which queues the
updated ticket would be in (and increment the count).