The now optional coordinate system argument of `POINT`, `BOX`, `CIRCLE` and
`POLYGON` MUST be a _string literal_.

_See <https://wiki.ivoa.net/twiki/bin/view/IVOA/ADQL-2_0-Err-3>_

& Allow UDF as valid geometry argument (a UDF being able to return geometries)
like in functions `AREA`, `CENTROID`, `DISTANCE`, ...

modifications of ADQL-2.1-PR)
+ Complete and fix case-sensitivity tests.

mature as defined in PR-ADQL-2.1 (see slides 26 of the talk
["Feedback on the implementation of ADQL-2.1"](https://wiki.ivoa.net/internal/IVOA/InterOpOct2019DAL/feedback_adql2_1.pdf)).

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.