Abstract queue generation into ResumableScan.

Turns out that queue generation's resume behaviour is very similar to
what's needed for scanning the files table for updates. I've abstracted
out the process into the ResumableScan class so that the two processes
can share the same code.

ResumableScan requires a ResumableScanInfo and a ScanProcessor. The
ResumableScanInfo stores information necessary for the resume function
and the table information needed by the ScanProcessor. The resume
function basically needs the last item processed's offset and value. The
ScanProcessor needs to be subclassed into a task specific processor.
E.g.: The QueueScanProcessor has queue generation specific code that is
executed for each row scanned by ResumableScan.

ResumableScan implements Runnable, so it should be run using Java's
thread mechanisms. This makes it easier to control execution. Like the
old queue generation code before it, ResumableScan checks for interrupts
every CSIndexJob.BATCHSIZE rows scanned.
Fix some files not being picked up.

Batches of files being processed will be forgotten if one of those
batches contain a file that hasn't been tagged. This is due to a wrongly
placed return which should've been a continue.
Add database reset functionality.

The database reset functionality just drops all data from this building
block's tables. It used to reside in a separate building block, but is
now integrated. The most complicated part is that clearing the database
also clears all of this building block's settings. This turned out to be
surprisingly problematic as many of the settings are cached. One thing
that I couldn't solve is that the UI requires a refresh in order to
retrieve the blank default settings. A message was put to ask the user
to refresh instead.
Update AngularJS to latest 1.2.15.
OnDemandIndexer obey CSIndexJob.BATCHSIZE.

OnDemandIndexer will refuse to process requests that are too large. The
size used to be hard coded, it is now replaced by the standard BATCHSIZE
used everywhere else.

Also removed test code method uselessGet().
Conversion to long from int for resume data.

Resume data consists of an offset and a file id. Turns out that the INT
datatype we use in schema.xml defaults to 38 digit numbers in Oracle.
This is too large of a number for a Java int to hold, an SQL exception
is thrown when the conversion is impossible to make. Converting all the
relevant ints to longs should make this a non-issue.

Also refactored the resume data retrival methods in preparation for
implementing the update index resumable scanner.
All 3 indexing stages now implemented

The 3 indexing stages are:
- Queue Generation: generate a list of all course files in the system
- Add New Files: process the queue, look for untagged files we haven't
  seen yet.
- Update Existing Files: scan our existing index, remove any files that
  have been tagged since we last saw them.

We now have a stage indicator on the configuration page to provide
information on what stage we're on.

The new staging system will allow continuous running of the building
block, without having to worry about unresumable operations. All 3
stages are resumable.

Update existing files stage was implemented in this commit. It uses the
ResumableScan operation like the Queue Generation stage, with the same
resume data (new entries in the hosts table) and mechanics.

Batch operations are now more utilized, hopefully it'll provide a bigger
speedup.