Adjust behavior of time bindings for immutable predicates and TYPE bindings for non-node objects

[rogerlucena]

We have two types of time bindings: AT bindings (using the AT keyword) and time anchor bindings (eg: "bought"@[?time]). In both cases, when extracting the time anchor from an immutable predicate like "parent_of"@[] we expect to see <NULL> in the query result. This PR comes to enforce this expected behavior.

To illustrate for the case of the AT binding, given the query below:

SELECT ?p, ?time, ?o
FROM ?test
WHERE {
    /u<peter> ?p AT ?time ?o
};

In a ?test graph having only the two following triples:

/u<peter> "parent_of"@[] /u<eve>
/u<peter> "bought"@[2016-01-01T00:00:00-08:00] /c<mini>

We expect as result:

Result:
?p                  ?time               ?o
"parent_of"@[]              <NULL>              /u<eve>
"bought"@[2016-01-01T00:00:00-08:00]    2016-01-01T00:00:00-08:00   /c<mini>

Note how the ?time binding is shown as <NULL> in the case of the immutable predicate "parent_of"@[]. For time anchor bindings such as "parent_of"@[?time] the expected behavior enforced by this PR is the same.

Note that this shall apply if we are extracting time bindings from objects that are immutable predicates too, in a reification scenario like in the clause below for example:

/_<BUID> "_predicate"@[] ?obj AT ?time_obj

On which, in the case ?obj is an immutable predicate as "parent_of"@[] we also expect ?time_obj to appear as <NULL> in the query result.

In a very similar way, withTYPE bindings for non-node objects the expected behavior is analogous. In the case the object is a predicate or a literal we will not succeed in extracting the node type and so we also expect, for now, a <NULL> in the query result. To illustrate, given a query like:

SELECT ?o, ?o_type
FROM ?test
WHERE {
    ?s ?p ?o TYPE ?o_type
};

In a ?test graph with only the following triples:

/u<alice> "height_cm"@[] "174"^^type:int64
/u<peter> "parent_of"@[] /u<eve>

We expect as result:

Result:
?o          ?o_type
"174"^^type:int64   <NULL>
/u<eve>         /u

Note how the extracted ?o_type is <NULL> for the literal object "174"^^type:int64. This PR, then, also comes to enforce this behavior for the TYPE keyword.

[rogerlucena]

I just broke this PR into two others: #127 and #128.