runmodel abstraction

[Eric Dean Tribble <tribble>]

Right now the handling of sets of attributes vs. AttributeHack objects
is a little confused.  Abstract models use iterators of symbolic
attributes.  DisplayModels turn these into runs of attribute objects
when they get created.  Since RunModels support Iterators of
attributes, they don't support AttributeHack objects.  

Here are a couple of directions to go:

Make runModels only represents sets of attributes.  DisplayModels then
do the attribute mapping and construct AttributesHacks on the fly
whenever they receive an 'attributesAt:' request.  This overhead
goes away with the appropriate caching.  This still requires the
DisplayModel to keep its own runArray for attributes not in the
AbstractModel (such as selection).

Make RunModel truely a Table implementation optimized for many shared
values.  The operations that currently add and remove attributes on an
enclosure go away.  The conceptual replacement is simple iteration
over all the elements in the enclosure.  For sets of attributes, each
element is a SetBang, and the add/remove rountines just directly add
or remove something from the set.  The real implementation just
applies the unaryFn for the add/remove op to the runObjects
representing groups of positions within the enclosure to be modified.
This lets us directly deal with either sets of attributes or with
AttributeHacks.  Again, this requires the DisplayModel to maintain its
own RunModel.  Oh well.

Of the two, I favor the former.  A RunModel as used by the frontend
would be a table from Positions to Sets.  The update protocol reflects
the protocol for adding attributes to enclosures defined for the keys.

comments?
dean