of the constructors of DefaultDBColumn and DefaultDBTable has changed!

about TAP_SCHEMA columns `schema_name`, `table_name` and `column_name`
(see tap_schema_requirements.md for more details).

of ORDER items, 3/ improve error messages in case of incorrect function argument
(especially in WHERE), and 4/ run JUnit tests for all ADQL versions (only in
TestDBChecker and TestADQLParser).

& Rename UnitConversionFunction into InUnitFunction.

done because the function must also be available in the database)

negative values).

The implemented operators precedence is:

```
[~-](unary) >> [*/] >> [+-] >> [^&|]
```

_**Example:** `~3-1|2*5^6/1+2 = ((~3)-1)|((2*5)^((6/1)+2)) = -5`_

previous commit, OFFSET was always available although it is actually an optional
feature.

in the ADQL-2.1 standard (in section 4.2.7).

Currently, geometries are not translated in MySQL and MS-SQL Server translators.
So, the preferred xmatch syntax has not been implemented in these translators.

(e.g. POINT, BOX, CIRCLE and POLYGON).

ADQLParser.

exist anymore.

ADQLParser is now a mix between the former ADQLParserFactory and ADQLParser2xx.
All ADQLParser2xx resulting from the compilation of the JavaCC files are
now named ADQLGrammar2xx and implement the new interface ADQLGrammar. The JavaCC
parsers are no longer used directly. This is the role of ADQLParser to simplify
the parser usage and to allow an easy switch between different grammar versions.

Besides, for more clarity in the class organisation, all generated parser
classes have been moved into the package `adql.parser.grammar`.

this is not any more possible.

provided. When done, all $$i (where i is the index of a parameter ; starting
from 1) are replaced by the SQL translation of the corresponding parameters.

creating the corresponding LanguageFeature. Now, FunctionDef throws a
ParseException when the UDF name is invalid.

used: `LanguageFeature(FunctionDef)`. This way, the syntax of the function
definition string is checked and function name and parameters can be correctly
extracted. These information are particularly important to determine at the
ADQLParser level whether a DefaultUDF is supported or not while not knowing the
parameters and function types.

(i.e. `Object.equals` instead of `==`).

instead of ONLY those listed in `availableFeatures`.

optional features of the ADQL-2.0 grammar (thus, supported geometries must be
declared as in the ADQL-2.1 parser: with the FeatureSet of the parser).

TODO: see how to throw errors when un-supported geometries are used in STC-S
      as done before at the DBChecker level.

are supported or not. All ADQLObject instances now have a new function allowing
to return a LanguageFeature describing the corresponding ADQL feature.

Only all geometric functions (e.g. POINT, CONTAINS) and the new ADQL-2.1
function `LOWER` are optional. By default, the ADQL-2.1 parser declare them as
supported. But their support can be changed at anytime thanks
ADQLParser.getSupportedFeatures() and ADQLParser.setSupportedFeatures(...).

In the current state, UDF declaration does not work anymore with the ADQL-2.1
parser. This will be fixed in a further commit. Besides, TAP has not yet been
adapted to use/configure the FeatureSet of the parser to use.

Anyway, the Javadoc of all geometric functions has been updated (so that being
conform to their description in ADQL-2.1) as well as the formatting of all
ADQLObjects (e.g. lines fitting on 80 characters, ...).

This function has indeed be completely removed from the ADQL standard (v2.1).

Fixes #121

Fixes #78
Fixes #60

This aims to prevent extending UserDefinedFunction for UDFs whose translation
is very simple (e.g. different name in SQL, different argument order, etc).

Fixes #115

Fix #52