Currently java.sql.Array is only supported when returned from the
database. Passing arrays to the database is not supported.
Connection#createArrayOf, PreparedStatement#setArray and
PreparedStatement#setObject with a java.sql.Array are not supported.

This pull requests implements passing java.sql.Array objects to the
database and includes the following changes:

 - implement Connection#createArrayOf
 - implement PreparedStatement#setArray
 - implement array support in ResultSet#getObject
 - implement conversion from java.sql.Array to Value
 - update DataType#convertTo to support arrays as well
 - add tests for #createArrayOf, #setArray and #setObject
 - add tests for #getObject with an array argument
 - remove the test for Connection#createArrayOf being unsupported
 - remove the test for PreparedStatement#setArray being unsupported

The typeName passed to #createArrayOf is ignored, this is in accordance
with JdbcArray#getBaseTypeName returning "NULL" and
JdbcArray#getBaseType returning Types.NULL even if the backing array is
homogeneous.

* Added parsing of table hints

* Implemented USE INDEX hints

* Added docs, tidied up code for submission

* Added docs, tidied up code for submission

* Removed used of final static field that would cause problems with Tomcat class unloading

* Removed used of final static field that would cause problems with Tomcat class unloading

* A table with no index hints now has indexHints == null, instead of an employ instance of IndexHints. For the common case of no index hints, this will prevent some unnecessary object creation.

* Index Hints now is backward compatible with using the "USE" as a table alias

* Added TestIndexHints to list of all tests

* Added index hints to text generated by TableFilter.getPlanSQL();

* Improved field names (a field called indexList was actually a set);
Added test for ensuring getPlanSQL lists index hints in correct order

* Improved unit test for making sure getPlanSQL renders index hints list in correct order

Cache Maven Local Repository

Now that we're on the Travis CI container based infrastructure we can
use caching for the local Maven repository [1] in order to speed up the
build times and reduce the load on Maven Central.

 [1] https://docs.travis-ci.com/user/caching/

* ISSUE-404 EXPLAIN should process statements with params placeholders.

* ISSUE-404 Fixed CommandRemote to support EXPLAIN with params placeholder.

* ISSUE-404 Fixed CommandRemote to support EXPLAIN with params placeholder.

* ISSUE-404 Support EXPLAIN with params placeholder WIP.

* ISSUE-404 Support EXPLAIN with params placeholder WIP.

* ISSUE-404 Support EXPLAIN with params placeholder WIP.

* ISSUE-404 Support EXPLAIN with params placeholder WIP.

* ISSUE-404 Muted tests.

* ISSUE-404 Fixed review notes.

* ISSUE-404 Un-muted tests.

no reason to be parsimonious here, can only help

CI still failing, maybe we have a memory leak somewhere in the tests?

so performance doesn't bottleneck on the synchronization in the FileBase
default implementations

otherwise client code will end up calling the version in FileBase, which
has unnecessary synchronisation

so we don't get warnings about the overriding methods also needing to be
synchronized, which is not the case

we're not interesting in exceptions in closing in these tests

since we require Java7, this is no longer necessary

to give us a thread dump when they get stuck

About #385 

Fix multi-threaded mode insert exception "Unique index or primary key violation", test case by Anatolii K

so we get nicer error messages when things fail

when run in memory mode, the initial connection used a memory DB,while
the second connection used a disk DB