Push more filters into SPARQL queries

[mmarx]

We're currently only pushing a very limited set of filters into SPARQL queries, e.g., LANG or DATATYPE. Figure out for which other builtins this is is safe to do (or, potentially, when this is safe to do), and push those as well.

[mkroetzsch]

This might need some thought on the underlying principle for deciding if to push or not to push. I suppose the current baseline is to identify filter functions that behave exactly as their corresponding functions in SPARQL, and to push all (possibly nested) expressions that consist only of such functions. I think most string functions should also be ok in this sense (Nemo also handles langStrings exactly as SPARQL would in such cases).

Many other cases are okay under additional side conditions, which might also be given in the filter, but as additional atoms whose presence would need to be checked. Most importantly, Nemo relations like < agree with SPARQL only for certain literal types (numbers should be fine, two gYears as well, but not string, nor mixed types [where SPARQL does not spec what should happen and each database may have a different behaviour]). Pushing inequalities could be very profitable, but side-conditions that fix the types of compared expressions are not so elegant (and certainly not what most users would add without hints).

Another possible case is when we compare expressions whose type is certain to be okay, such as LOG(?x)<LOG(?y). This might be an elegant middle ground between only supporting fully compatible functions and requiring side conditions. To get this working, one would need to reason about return types (and think about how to represent this internally, e.g. "numeric" types work for < even though the union of these types is not represented by any xsd type).

[mmarx]

In particular, we should also handle OR (conjunctions of filter expressions are already handled).