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

not be set because of the current execution phase.

Fixes #123

```
RESTORATION Incorrect JSON format for the serialization of an uploaded file!
Caused by a org.json.JSONException: JSONObject["length"] not a string.
[...]

RESTORATION Incorrect JSON format for the DALIUpload labelled "xxx" of the job "xxxxxxxxx": "xxxxxxxx" is not pointing a job parameter representing a file!
[...]

RESTORATION Unexpected error while restoring the UWS!
Caused by a java.lang.NullPointerException: Missing UploadFile! => Can not build a DaliUpload instance.
[...]
```

Now, in case of grave error while restoring backup files, it will be just
disabled, instead of preventing start-up of the TAP service.
In case of non-grave error while restoring a job or a user, the failed job or
error won't be restored and then the restoration process will go on with the
other jobs/users.

when ending the query with an EOF.

This commit reverts commit 89418d13.

The reverted commit will be applied in another branch (probably 'adql-2.1') as
it is part of the next release of ADQL-Lib.

- Now, `ADQLParserFactory.createParser(...)` should be used to create a parser
- Only the new function `LOWER` is supported for the moment
- Not yet possible to manage the optional features _(next dev to come)_
=> 1st step for ADQL-Lib v2.0

- TAP adapted so that using the last stable version of the ADQL language
  (i.e. 2.0 for the moment)
  - but not yet possible to set the ADQL version to use in the configuration
    file

In case a MIME-type parameter was not `q` set to a floating point value
(e.g. correct is `q=0.8` ; incorrect is `q=abc`), the library was throwing an
ugly NumberFormatException. This exception is now caught (and ignored) if it
occurs.

The same exception was also thrown for any other parameter whose value is not a
floating point. Since only the quality flag (i.e. `q`) is used in UWS-Lib,
parameters are now only parsed if it is `q` ; all others are now ignored.