Queries can leak hidden information through `count`

relates to #114

I think theres a hypothetical privacy flaw in my collections cache design:

• Create a Query with some value from which you suspect that exists somewhere that you aren't allowed to see. Let's consider someone has a private resource containing a secretLover property. You do a search for this property.
• When fetching the results, you will not see the hidden item, but you might see a count that shows that something is hidden. Ok, you now know that there is someone with a secretLover!
• Try filtering by various Values, and you may see the count value increase by one. If you got it right, you know who the secret lover is. Whoops!

The reason this will happen, is because the indexed query system is quite fast in returning the amount of hits for some query, but checking if every one of these hits is authorized is... expensive.

So what can we do about this?

Add a new key to the index

Like... Some rights resource? But this can only be a string, such as the publicagent string. Not sure if that will ever be enough.

We could add the Agent to the QueryFilter. But this will lead to an immense growth of indexes, potentially one for every user + query combination. Doesn't scale.

Don't show count

Which also means no total pages... Seems pretty bad.

Redesign how pagination works

Instead of counting the pages, we can use start_value and end_value from Queries to construct pages.
This does mean we don't know at which page we are, and how many there are left.

Check all subjects

Slooowwwww

Start by tracing the collections cache, indexed query system, QueryFilter, and the count and pagination values described in the issue. Determine how authorization affects returned hits and counts; done means hidden resources cannot be inferred through count or filtering, with the pagination behavior explicitly defined.