Error with large number of items

I am adopting the patch from #8 as a much-needed solution for the rendering limit and general performance issues. I agree with the suggested refinements but for now this makes it possible for me to provide the site functionality.

There seem to be some unrelated changes in this patch.

Instead of hacking things out in prerender -- when the entities have been loaded already, which is going to be one of the big causes of poor performance -- I wonder whether we can restrict the query.

The answer here using LAG and LEAD looks promising -- https://stackoverflow.com/questions/32036864/select-a-row-and-the-rows-e...

I can get this to work by hacking in the Views SQL plugin and wrapping the returned query:

    $query->addExpression('LAG(node_field_data.nid) over ()', 'lag_nid');
    $query->addExpression('LEAD(node_field_data.nid) OVER ()', 'lead_nid');

    $outer = $this->getConnection()
      ->select($query, 'inner');
    $outer->fields('inner', []);
    // $outer->condition('lag_nid', NID, '=');
    // OR
    // $outer->condition('lead_nid', NID, '=');

    return $outer;

This POC shows that it's possible to wrap the query in another, and use the lag/lead expressions.

However, to use this we need:

- to switch the query plugin, and Views only allows base tables to specify a different query plugin. We really don't want to have to redefine EVERY table (and expect users to know to use a different base table). What we could do is override getPlugin() in DisplayPluginBase, which would mean we need a custom display. But having an 'Entity Pager' display type makes sense.
- we need the current entity ID to pass to the query as a condition. We could do the same technique with the route match, though doing it that deep in Views feels a bit wrong -- would be nicer to have it as a default argument plugin.

> to switch the query plugin

I think this is actually possible in the pager plugin after all.

Done!
I've actually added two techniques for optimisation -

- pre-query, using LAG() and LEAD() as described above. This will scale best to very large result sets, but the query alteration might cause problems with complex queries (such as using GROUP BY, maybe -- I've not experimented)
- post-query, removing rows from the result that are not relevant. This is similar to the patches above, but crucially runs *before* the SQL Views query plugin loads the entities for each row. It will still not scale as well, as for very large result sets, the whole initial result is still loaded into PHP -- but it's probably fine up to several thousand rows.

Please review!