This is a basic implementation of the SPARQL VALUES pattern type.

Three approaches considered:

1) just document that :values needs to appear first
2) discard solutions that don't match the given solution
3) during the parse step, sort the patterns so :values is first

I don't like #1, though that's the most expedient. #2 is a bit wasteful as it forces us
to generate useless solutions. #3 is doable, and may be a minimal requirement in basic
query planning.

This implements solution #2.

Change 1: handle multiple inline values correctly.

Instead of checking that _every_ inline solution equal the solution matches, we needed
to _filter_ the inline solutions by whether they match the solution. If any matches, the
values can contribute their solutions to the solution chan.

This case allows multiple values to be handled correctly, as seen in the "pattern"
"single var" test.

Change 2: do not consider ::sids while checking match equality

When dealing with federated queries the ::sids map may be different for the same
value. We now dissoc the ::sids key from the solution matches before checking equality.

This is verified by the "federated" test case

Change 3: only consider :lang ::meta while checking equality

Two identical strings with different language tags are different values. However the :i
order or whether it comes from a reasoned flake do not matter for equality checks. We
now select only the :lang ::meta key, if ::meta exists in the solution match.

Language tags were not parsed, so I've added parsing support for that.

In the future the contents of a match may change, so instead of removing specific
unwanted elements we now extract only those elements of a match that establish its
identity for equality checking.

We were not parsing language tagged strings to langString datatypes correctly in where
patterns or in values patterns, nor inferring a langString datatype in the presence of a
language tag.

I had to update the test expectation because now the language tagged string no longer
conforms to the `sh:maxCount 1` _and_ the `sh:datatype xsd:string` constraints, instead of
just the `sh:maxCount` constraint.

In SPARQL, a VALUES pattern can appear inside a WHERE clause alongside other
patterns. In FQL :values is its own clause. This mismatch makes translating directly
awkward, since we need to insert our translated pattern at a different point in the
parse tree than where we are at translation time.

We got around it by translating it into a :bind pattern. However, a :bind pattern can
only bind a single value to a variable, so we limited the scope of a VALUES pattern to
only a single value.

This gets around it by "tagging" the translated value pattern and then after the whole
parsing is done, moving it to the correct place in the tree: see `format-values`. It's
awkward, but it gives much more flexibility to the user.

FQL now supports :values patterns so we can use that directly instead of translating to
a :values clause.

The tricky part is deciding when to `literal-quote` one or more of the args. Since that
information does not exist in the parse tree at the point where :Func needs parsing, we
need to figure out whether to quote based on the signature of the function, according to
the SPARQL spec: https://www.w3.org/TR/sparql11-query/#SparqlOps and the SPARQL grammar.

This way is more repetitive but more robust. Once we've got all the functions covered we
can search for abstractions to reduce verbosity.

I'm not sure where the LANGTAG regex came from, but it didn't match the one in the spec
- it required the hyphen (-) between two-part lang tags of the style `@en-us`, but
disallowed the simple verson `@en`. Now it correctly accepts both.

The grammar wasn't expecting whitespace between the 'a' and the prev/next term.

Semantics and syntax from SPARQL IN expression.

It's not sparql-specific, so no need to qualify it.

The :Expression parser was turning everything into a string, which works in some cases
but introduces unwanted quoting in others. By deferring stringification until values
need to be incorporated into an actual string expression we avoid the unwanted quoting.

Do note that all the numeric functions now correctly expect numeric values instead of
strings.

abs expects only a single expression as an argument, and that argument does not need to
be quoted.

translate SPARQL IN/NOT IN expresssions into FQL

translate SPARQL EXISTS/NOT EXISTS filters into FQL

add support for `in` expression

Feature/fql exists not exists

Feature/sparql from named

Feature/sparql func