Rewrite queue processing system to fix problems when there are multiple items in the publishing queue

We saw a problem on a site which somehow wound up with multiple items in the CPS publishing queue. It is not clear exactly how it got into that situation, but it probably had something to do with the fact that cps_process_queue_page() does not always claim items that were created for it, nor does it always release items that it has claimed.

Once that happened all hell kind of broke loose, because cps_process_queue_page() does not always guarantee that it will grab something from the queue associated with the requested changeset; rather it grabs the first item it finds and then silently fails if that item is associated with a different changeset. So people kept trying to publish changesets and just saw a "Processing" message appear on the screen and hang there, with the changeset never published. And the more they did that, the more the problem got worse.

The workaround was to clear the processing queue via the UI, but we should avoid this situation happening in the first place.

This patch fixes a number of issues related to the above:

1. Fixes cps_process_queue_page() so that only queue items associated with the requested changeset are grabbed.
2. Incorporates changes from #2671588: Queue UI clean-up (but rewritten to work with the rest of this patch) so that multiple queue items aren't created for the same changeset in the first place.
3. Makes sure that if cps_process_queue_page() ever does fail it fails gracefully, with appropriate messages displayed to the screen and cleaning up after itself as much as possible.
4. Fixes issues with the locking code while a changeset is being processed; since locks currently get extended within a database transaction, that has the effect of making other requests trying to do something with the same lock hang. This can't be avoided entirely, but this patch minimizes the scenarios under which it will occur.
5. Makes the code that marks a changeset as "publishing" (while it's in the process of being published) run before the database transaction starts (otherwise it doesn't seem to have much effect; other requests won't see it until it's too late), and adds a similar "unpublishing" status for changesets that are being unpublished.

Note that this patch is written so as to apply on top of several others currently in the issue queue:
#2693087: process_status.js can hang when a changeset is being published
#2693721: Publishing or unpublishing a changeset should redirect to the live site
#2693723: After publishing a changeset, the changeset sometimes still appears as if it's unpublished for one page load