add parser-based validation for JPQL, SQL, HQL snippets

[martinlippert]

Add validation logic to the language support for JPQL (etc.) wherever those languages are being used (annotations in Java source code, named query files, etc.).

The validation should report messages from the parser to the user in the form of diagnostics, as usual. The more detailed and fine-grained, the better - depending on that is possible using the parser at hand.

[BoykoAlex]

I'd factor out SQL is a separate issue as we don't have SQL parser and semantic token syntax highlighting for SQL. At the moment all SQL support comes from upstream extensions and syntax highlighting for SQL is somewhat restricted by what upstream extensions/plugins provide. There is no semantic tokens syntax highlighting from Boot LS provided for native SQL (but we can change that of course)

[BoykoAlex]

JPQL and HQL are in with 385c35e

[BoykoAlex]

SQL was the last one. Went in with fe953bd

[pcdavid]

It looks like the SQL parser only knows about MsySQL's syntax (from the file name)?

In our case we use PostreSQL-specific syntax and with the update to 4.23 I now have an error marker as the parser does not like/understand PG's type-cast syntax using :::

SQL: no viable alternative at input 'DELETE FROM Representation representation
            WHERE representation.project_id=?1
            AND NOT EXISTS (
                SELECT * FROM Document document
                WHERE document.project_id=?1
                AND jsonb_path_exists(document.content:'

Is there a way to disable these checks?