* Added WITH to CREATE SCHEMA to supply default TableEngine params

* Updated docs to reflect changes in CREATE SCHEMA

* Review fixes - docs; code de-duplication; test for table engine params in schema

* Setter for table engine params in Schema

Optimized column vs constant comparisons

unfortunately I had to hit it with the big synchronization stick. I
could no simple way to rescue the current rather clever code.

This bug was reported by Anatolii K  in this message:
https://groups.google.com/d/msg/h2-database/rhSoRhzeZzk/gc-pNlSpEwAJ

Issue #434 - parse engine params in CREATE TABLE w/o engine specified

Add target to gitignore

Currently the target/ folder is not in .gitignore this gives me changes
when I compile the source.

we don't seem to be keeping this up to date anymore

# Conflicts:
#	h2/src/docsrc/html/changelog.html

Some typos snuck into debug log messages causing a wrong class name to
be logged.

Update Changelog

Some PRs merged into 1.4.193 and 1.4.194 are missing from the
changelog.

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