Enable complex constraints

[GordianDziwis]

When we click a facet, we should have e.g. a tabbed pane for how we want to create constraints.
The prior versions always had this 'click on a facet value to create a constraint' thing.
But in the API we can e.g. do

facetNode.constraints().between(foo, bar).activate()
facetNode.constraints().greaterThan(baz).activate()

So we could have a separate tab where we show a sliders to create/update/delete range constraints.

The API even has a method to get all values NOT affected by constraints facetNode.fwd().nonConstrainedFacetValueCounts() It is useful in the benchmark to find out what has not yet been constrained - maybe its not that useful in the UI :)

Originally posted by @Aklakan in #18 (comment)

[Aklakan]

We also need to think about how we could add a "conjunctive mode" for the facet values:
For example, consider a 'keyword' facet: Right now whenever we click any values, such as "Semantic Web" and "Big Data" the resulting query uses the disjunction (i.e. ?keyword = "SW" OR ?keyword = "BD"). However, in many cases we want to be able to create conjunction, such as which items have BOTH keywords. The API itself currently supports (though hardly tested):

facetNode.fwd().via(keyword).alias("alias1").constraints().eq("SW").activate();
facetNode.fwd().via(keyword).alias("alias2").constraints().eq("BD").activate();

which corresponds to the sparql element

?facetNode keyword ?keyword_alias1
?facetNode keyword ?keyword_alias2
FILTER(keyword_alias1 =" SW")
FILTER(keyword_alias2 =" BD")

which is already what we want to generate.

However, there is no method that automatically allocates a new alias when a facet value should be added as a conjunctive constraint.
Furthermore, I am not sure to what extent the facet value count graph pattern generation needs to be modified. In "conjunctive mode", the facet values should indicate the number of remaining items when adding a facet value as an equals constraint to the set of already active constraints.
Constraints on different properties are naturally treated as conjunctive constraints.

My impression is, that if we consider uses of the same property with different aliases just like they were independent properties that we may be able to naturally get the desired result (i.e. the constraints of e.g. (keyword, aliasFOO) and (keyword, aliasBAR) need to be handled independently).
In that case we may only need a few carefully designed API methods with smart bookkeeping/lookups for the alias allocation/management without having to change the query construction.