FILTER keyword for latest anchor queries (planner/memory)

[rogerlucena]

This PR comes as a part of #129, finishing to set up a FILTER keyword in BadWolf at the planner and memory levels. The first FILTER function chosen to be implemented is the latest one, solving what was requested by #86.

It would be very useful to have in BQL a FILTER keyword that could allow us to filter out part of the results of a query in a level closer to the storage (closer to the driver), improving performance. This is exactly what this PR finishes introducing, completing what started with the PR #149. This PR also showcases the full implementation of how this keyword could work on the driver/storage side as well (exemplified with the changes added to the volatile open-source driver in memory.go below).

Then, now the user can specify, inside of WHERE, which bindings they want to apply a FILTER to, proceeding with a more fine-grained lookup on storage, avoiding unnecessary retrieval of data and optimizing query performance.

To illustrate, queries such as the one below are now possible:

SELECT ?s, ?p, ?o
FROM ?test
WHERE {
    ?s ?p ?o .
    FILTER latest(?p)
};

That would return all the temporal triples of the ?test graph that have the latest timestamp of the time series they are part of (a recorrent use case in BadWolf), skipping immutable triples found along the way. This FILTER function also works for objects ?o in the case of reification/blank nodes: in this case the returned triples would be the ones on which the object is necessarily a temporal predicate with latest timestamp among the predicates with that same predicate ID (in the "object" position of the clause), analogously to what happened with ?p.

This FILTER for latest anchor above also works for alias bindings obtained with the AS keyword for predicates and objects too.

At the moment only one FILTER is supported for each graph clause inside of WHERE, and only one FILTER is supported for each given binding as well.

In the future, to add a new FILTER function, the steps to follow are:

1. Add a new enum item in the list of supported filter Operations in filter.go;
2. Add a new entry in the SupportedOperations map in filter.go to map the lowercase string of the FILTER function being added to its correspondent filter.Operation element;
3. Update the String method of Operation in filter.go;
4. Add a new switch case inside compatibleBindingsInClauseForFilterOperation in planner.go to specify for which fields and bindings of a clause the newly added filter.Operation can be applied to;
5. Implement the appropriate behavior on the driver side.