Test that cache evictions propagate to parent queries. (#6412)

When an object is evicted from the cache, common intuition says that any
dangling references to that object should be proactively removed from
elsewhere in the cache. Thankfully, this intuition is misguided, because a
much simpler and more efficient approach to handling dangling references
is already possible, without requiring any new cache features.

As the tests added in this commit demonstrate, the cleanup of dangling
references can be postponed until the next time the affected fields are
read from the cache, simply by defining a custom read function that
performs any necessary cleanup, in whatever way makes sense for the logic
of the particular field. This lazy approach is vastly more efficient than
scanning the entire cache for dangling references would be, because it
kicks in only for fields you actually care about, the next time you ask
for their values.

For example, you might have a list of references that should be filtered
to exclude the dangling ones, or you might want the dangling references to
be nullified in place (without filtering), or you might have a single
reference that should default to something else if it becomes invalid. All
of these options are matters of application-level logic, so the cache
cannot choose the right default strategy in all cases.

By default, references are left untouched unless you define custom logic
to do something else. It may actually be unwise/destructive to remove
dangling references from the cache, because the evicted data could always
be written back into the cache at some later time, restoring the validity
of the references. Since eviction is not necessarily final, dangling
references represent useful information that should be preserved by
default after eviction, but filtered out just in time to keep them from
causing problems. Even if you ultimately decide to prune the dangling
references, proactively finding and removing them is way more work than
letting a read function handle them on-demand.

This system works because the result caching system (#3394, #5617) tracks
hierarchical field dependencies in a way that causes read functions to be
reinvoked any time the field in question is affected by updates to the
cache, even if the changes are nested many layers deep within the
field. It also helps that custom read functions are consistently invoked
for a given field any time that field is read from the cache, so you don't
have to worry about dangling references leaking out by other means.