share 1 connection when flushing the db queue instead of opening a lot of connections
catch exception in rare cases when bukkit fails to get the location of a block when interacting with an inventory
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.
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.