Initial database write capability.

Basically a proof of concept to see if we can write to the database.

The start of the functionaly to write the queue of files to the database
so that they can be processed. We want to write the entire file list to
database first and then process it. Processing will take place in
batches of 500. Load the first 500 entries, process each one, and then
remove those 500 entires. Repeat.

One major problem with getting a CSContext in a Quartz job is that there
is no User account associated since Quartz was started on servlet
initiation and not when a user visits a page. So I had to create an
empty user object, set it to be an SYS_ADMIN and use that to get a
CSContext. Not sure if it'll result in errors later on, but it works for
now.
Processing queue now properly created.

The indexing thread will now properly search through every directory in the
Content Collection in a breadth-first manner starting from the root
directory. Each file encountered is recorded into the ubc_ctlt_ca_queue
database for later consumption.

Encountered a ton of problems with the API.

First, the database connection didn't seem to like batch operations.
Would instantly make the Oracle database unconnectable if I use it. This
might have been confounded with the next bug though, so will have to
revisit batch operations later.

Next, the database connection pool would seem to get exhausted after a
while, rendering the database unconnectable. This was solved by properly
releasing the database connection in each database access method.

Finally, the Content collection API is very resistant to being called
without a proper user context. Since the indexer thread was created
before there could be any user context in the servlet init, I had a lot
of exceptions. Worked through fixes including various ways to fake a
user for CSContext, none of them worked for all cases. It seems even
though you pass a user to CSContext, some CSContext calls won't
necessarily use that user for it but instead tries to grab the user from
the Blackboard Context. Which fails since there's no user context. This
diagnosis was only possible by decompiling the API library jars. The fix
was to set CSContext to be a super user.

Next up is letting users configure the building block to recognize the
proper metadata attribute IDs so we know whether or not a file has been
copyright tagged.