Fix duplicate file alerts.

Some instructors may see a file show up more than once in alerts. This
can happen if they're teaching two courses that both use that file. When
grabbing the list of instructors that has permission to access that
file, it's a course based operation, so it'll list the instructor twice
since they teach both courses. Fix is to just change the list of users
to be stored as a set.
"Running" status now has 3 stages.

Previously, the status indicator in the configuration page would just
say "Running" and you wouldn't know if internally it's generating the
queue or actually processing the queue. This kind of information turns
out to be helpful in troubleshooting, so adding more detail to the
Running status was necessary.

I've now split the building block's running status into 3 stages:
* Queue Generation - Iterating the file system, looking for course
     files.
* Adding New Files - Going through the queue, adding in files that we
    haven't seen before.
* Updating Old Files - Goes through the files table, removing files that
    have been tagged. (To Be Implemented)

Updating the old files used to be done by the "Adding New Files" stage,
cause we drop the entire files table before generating the queue. It
looks like, due to the sheer amount of files in the system, that would
be counterproductive since it takes sooo long to generate the index. So
now I have to build a new stage for updating the old files instead of
dropping them all.
Merge constants for the size of batch operations.

There's two constants being used that determine the size of batch
operations (how many files to be inserted at a time, etc). One was in
CSIndexJob and one was in QueueTable. I've merged them to a public
constant in CSIndexJob for convenience.
Add Queue Generation Resume support.

Turns out that there are so many files that queue generation may be
interrupted before it completes. So there needs to be a way to resume an
interrupted queue generation process.

Two fields were added to the HostsTable which stores the progress of the
queue generation when it's interrupted. See associated comments for what
they do. These fields are updated to the same value for all hosts.

The queue generation method was modified to save queue resume data every
BATCHSIZE files it encounter.

The SQL query used to retrieve files from where we left off may be a bit
slow due to the sheer amount of files we have to go through. It uses
ROW_NUMBER() to assign row numbers to each file. We're sorting the files
by file_id. file_id is an indexed field, which according to some
comments online, means that assigning row numbers *should* be very
efficient. Same with the sorting, because it's indexed, sorting
shouldn't take very much. We're using the location of the last processed
file as a kick off point for resuming queue generation. If that file was
deleted, then we just take a best guess by using the last row number
that we saw, which means some files may be missed. I'm assuming that
deletions don't happen that often, so missed files can just be picked
back up in the next cycle. Another assumption is that the file_id always
increases, it doesn't reuse old file_id, which *seems* to be the case.

Note that a previous attempt at the same SQL query used the "OFFSET"
mechanism to skip files, but it turns out that the version of Oracle
we're using is too old, so doesn't support "OFFSET" operations.
FilesTable, check for duplicates before adding new

Only add new entries if they haven't existed before. The FilesTable now
have indexes on fileid and userid, to speed up the duplicate check and
to speed up the user data retrival.

Also converted adding new entries to a batch operation in order to
increase performance.