Dev fix history unlabeled

[AstridKery]

The function to show unlabeled data was ignoring data in the "normal" queue instead of ignoring assigned data. The normal queue is the precursor to assignments, and is filled automatically by SMART when data is uploaded or the items in the existing queue are labeled.

The affect of this issue was that there was ~30 unlabeled data that wouldn't show up in the skew page or when someone selected "unlabeled data" in the history table, even if it wasn't assigned to anyone. The fix is two parts: first to stop excluding items in the normal queue when returning unlabeled data, and second when unlabeled data that is in the normal queue is labeled in the history or skew page we need to remove it from the queue so it doesn't ever get assigned.

[AstridKery]

Expected behavior from this MR:

• before the changes, the quantity of data returned when either checking off unlabeled data in the history table or going to the skew tab would be (total unlabeled and unassigned) - batch size
• After the changes the amount of data returned should be equal to the count of (unlabeled + unassigned) on the details page
• These changes are meant to update the queue when a queued item gets labeled in the history/skew page in the same way they do when someone labels it in the annotate page. The queue should also get refilled if it was empty from someone labeling everything in history, so that if they go to the annotate tab later it works properly.

[andykawabata]

I tested this branch to make sure the skew and history(unlabeled) tabs were showing all unlabelled + unassigned data. To test this I:

• created a project with 25 data
• checked to make sure history and skew pages had correct counts
• labeled some data and checked again
• went to the annotate page as a different user to fake "assign data" and made sure counts were still correct

The skew and history pages had correct counts throughout, however I realized that the project details page was not showing the correct count for "Unlabeled and Unassigned". Proposed fix in this PR:

#319