share 1 connection when flushing the db queue instead of opening a lot of connections
Fixed build errors in the SQL interface with JDK 7

As of JDK 7, the JDBC interface introduces new methods into two of its
classes: PreparedStatement and ResultSet. This needs to be accounted
for since many people will be building with JDK 7.
Ensure protections are of allowed types before attempting to find them

Queries were being run to check for protections even on blocks that are
not protectable. This leads to a significant amount of extract SQL
traffic, and blocking operations in the Server thread assuming that not
all protections are cached.

Before any database queries are executed, ensure blocks are of the
allowed protection types.
Handle all protection lookups with internal cache

LWC has a *bad* implementation currently for loading protections, which
leads to a lot of useless SQL traffic. This makes for many blocking
operations in the Server thread that are essentially doing nothing, but
creating TPS issues.

If a protection did not exist in the cache, an SQL query was executed
to determine if the protection existed in the database. If the
protection was found in the database, it was added to the cache and
returned to the calling stack. However, if the protection did not exist,
nothing was added to the cache or returned to calling stack. This is
problematic for events such as the BlockPistonExtendEvent, as often
times it is running endless SQL queries because nothing exists in the
cache and probably never will.

To alleviate this issue, everything is loaded into the cache initially
and stays there. This does carry with it its own overhead in terms of
not only memory, but *possibly* lookup times in some cases. This method
uses around 33M for 22K protections. The memory usage, is a fairly
respectable trade-off for a significant drop in the amount of blocking
SQL queries. Even the process of obtaining values from a huge Map should
perform far better than running all of the repeated SQL queries.
Furthermore, depending on the cache settings, it was possible that the
protections would have been completely loaded into the cache during the
server's uptime.