Support `loadSubset` deduplication in query collection

[kevin-dp]

In #835 we disabled the deduplication of loadSubset calls inside the query collection because there were some problems with garbage collection of queries which would lead to deduplicated queries to use stale data from the local collection (because the query they depend on was the one loading updates from the backend but is now GCed).

However, we do need to optimize the query collection such that we do not fetch data we already have locally and integrate it smartly with GC such that we detect when data becomes stale and needs to be fetched from the backend. The main problem came from the fact that we did reference counting on a per-row basis, we're thinking that it would be more maintainable on a per-query basis, i.e. if query 1 loads some data and query 2 is deduplicated because of query 1, then query 1's ref count is essentially 2 (meaning that it can only be GCed after query 2 has been GCed).

[TimFL]

I don't think this is an easy thing to solve, especially if you look at the whole spectrum of possible predicates / subsets. When I query for ids / keys, it becomes pretty easy (because we can directly map an id to a record in our collection), whereas more exotic predicates that map to properties can't actually be deduped reliably (since it would be naive to take any cached content as the full truth ... imagine querying for all users that have been active within the last 5 minutes via e.g. gte(user.lastSeenUnix, Math.floor(Date.now()/1000) - 1000*60*5), by the time I mount a new query with the same predicate, I might have a completely different set of users returned / none returned). You always risk showcasing stale data when you deduplicate, regardless of what staleTime is specified.
I don't think any amount of deduplication work or brainstorming is going to solve the staleness issue we will face with deduplicating ambitious queries (e.g. queries not tied to an identifying property like the key / id).

---

In case of strict predicates, e.g. querying for ids / keys (e.g. eq(user.id, "123") or inArray(user.id, ["123", "456"]), it becomes much easier to handle since you already know what you're expecting (user with id 123 or 456).

If you're just looking at it from a "grab entity by key / id" angle, it could be pretty easy to solve even on the developer (people using this framework) side.

My current implementation wraps every entity in a makeshift DbSyncMetaRecord, which resolves to this:

type DbSyncMetaRecord<T = unknown> = {
	id: string | number;
	record: T;
	lastUpdate: number;
};

The idea is, that every entity / record is added to the collection wrapped in this structure, where lastUpdate is the current unix timestamp from when the data was pulled in by the queryFn from the remote endpoint / API. That way I know exactly when each e.g. user object hit my cache.

Now when I go ahead and mount a second query, the queryFn could find all cache hits via the id filter, compare the lastUpdate timestamp against the current unix and factor into the staleTime and determine, whether the filter should include that specific id or not. If userid 123 was mounted 2 minutes ago, but my collection staleTime is 5 minutes, it could be pruned from the predicate that is sent to the API while instantly returning the cached user record (and pulling in the remaining ones async). If it's considered stale (NOW - lastUpdate >= 5 min), it's kept in the predicate so the existing record gets pulled in fresh from the API and is updated with the remaining batch.

This is acceptable behavior for my app currently, seeing as I only have a need for querying by id at the moment.