Using the WITH clause is already a pre-requisite for * and + operators
(as those queries need to be recursive). It then struck me that using
it for all path operators is simpler and easier to read both in code and
SQL, for starters:
  - We were going long ways to invert the processing order of VerbPath and
    ObjectList, so the latter would be handled within the former. This was
    necessary so we could eg. invert subject and object in ^.
  - Each property path element results in a rather simple SELECT in the
    WITH clause, and nesting those comes off naturally. This is handy as
    a property path is actually an expression tree, which we weren't
    handling that well.

As a first step, add this infrastructure for property paths using the WITH
clause and use it for the currently supported operators.

We still fall through the usual code paths (no subqueries in WITH clause)
if the property path is formed of a single literal with no operators
(i.e. the good old "?s foo:bar ?o" case). This is still necessary for
fts:match (which is not really a property, thus can't be used in property
paths) and rdfs:domain special casing (which just applies if the predicate
is a variable, not the case with property paths).