Improve efficiency of some set aggregates

UR::Object->__changes__ now accepts a list of properties to check for changes.
The default is still to check all properties.

Set aggregate functions like sum, max, etc use that new functionality to check
if the changed member objects have changes that would affect the result of the
aggregation.
Fix a bug with unloaded UR::Object::Join instances

The previous commit made __changes__() on newly __define__ed objects report
false.  This tripped a bug where a rolled-back software transaction would
unload UR::Object::Join objects needed by QueryPlan.  Prior to that commit,
these would not have been unloaded.

The unloaded Joins hung around in the package-local cache used by
UR::Object::Join::resolve_chain() as DeletedRefs
An object's class must be is_uncachable in order to be unload()ed

The check for is_uncachable() is changed so that during the check for
is_uncachable on parent classes, _all_ parent classes must be is_uncachable
before we decide this one is.

This required changing the parentage of FileMux spawned datasources so they
all inherit from a common class that gets set to is_uncachable = true.

The added test verifies that data sources aren't unloaded after a rollback
Move all the set's cached values into a common key

It'll make it easier to invalidate the cache later
Set's cached aggregate values are removed when the members change

It's smart about deleting in that a change to the set membership
removes all cached values, but a change to a non-membership property
only remove the aggregates dependant on that property
Set aggregates always trust the cached value when it exists

The member-class callback removes the cached value when you can't trust
it anymore
Test that cached aggregate values are expired when member values change

But that unrelated aggregate values are kept
Sets track changes in membership with a flag

The flag allows a set to know when an object starts out as a member, and
later changes to be not a member, either because it gets deleted or because
a member-defining value changes

Added tests to confirm that the aggregate value cache is wiped out when set
membership changes
Update the deps cache anytime we've calculated an aggregate

not just when we did it in the DB
Only set the __members_have_changes flag when a create/delete was to a set member
Clear the __members_have_changes flag when the Context commits
Rename variable
Check for dependant aggregates before evaluating the object against the rule

By checking for a hash key first, it'll be a bit faster for the cases where
the changed property isn't in the dependancy list because we don't have to
evaluate the rule
More comments to explain recent set changes