Allow to sort by any field in the entity query

[idimopoulos]

Currently, in the \Drupal\sparql_entity_storage\Entity\Query\Sparql\Query::addSort, only id and rid are supported.
This is not very permissive and we should support sorting by any field.

The implementation has its tweaks though. Take the following example.

select ?subject ?predicate ?object
WHERE { 
  ?subject ?predicate ?object .
  ?subject  a <licence url>
}

In the above query, we are querying for all properties of the objects that have a type of <licence url> (pretend this is a URL :D)
This is equivalent (more or less) to the SQL query

SELECT * FROM <table name>
WHERE `type` = `licence`;

pretending that the licence is the type.
Now, in a normal SQL query, if the table had the column label, we would be able to simply add a sort of that column simply because it is included by the table by default. However, we cannot do that for the SPARQL query as there are no columns and they don't have names.

Following the above, there are two things we need to do here:

• Generate a variable for the field to add it to the query. We are already doing something like this in the \Drupal\sparql_entity_storage\Entity\Query\Sparql\SparqlCondition::compile in the following piece of code

        $field_name = $condition['field'] . '__' . $condition['column'];

so we are adding a field with the corresponding column. We have exceptions for the entity ID I think.
This is a quite easy part as the Query class already takes the field hanlder as a dependency.

The second part is a bit tougher but we are kinda lucky.
As noted, we cannot add a field column bluntly. We need to define it in the "WHERE" clause, i.e. include it as a condition. What needs to be done is to calculate the field property above and check right before the query is compiled, if at least one condition is applied on this field.
If a condition is not applied, then we have to add the default condition of

?entity_id ?predicate ?field_name__field_column

Important notice: Not 100% sure but when using the above line, the query requires this triple to exist. So this would exclude from the query, results that don't have the value. This is not what happens in SQL where the non existing value is perceived as an empty string.
If that is the case, we would have to create a more complex structure of UNION where we would bind the field value as a string where we bind it as empty is it does not exist. Then the sorting will handle it properly.