New Model structure

[Eric Dean Tribble <tribble>]

A  model is an object that broadcasts a notification of changes made
to it to any interested Object.  The existing Model implementation
isn't quite adequate for having Tables and Sets be Models.  The
problem was that many Table classes (all ImmuTables, for example)
never change and so never broadcast any changes.

The solution is to have a Model class that declares the protocol:

addDependent(dep) - broadcast future changes of the receiver to dep.
removeDependent(dep) - stop broadcasting changes to dep
hasDependents() - return true if there are any dependents.
changed(updateRecord) - broadcast the change representd by updateRecod
to all dependents.

The implementation in Model does nothing.  Subclasses that actually
broadcast changes use the declaration HAS_Dependents which expands
into the code for the dependents protocol that actually does
something.

This gives:

-- a type distinction between classes that could have dependents and
those that can't.
-- an implementation distinction between objects that actually
broadcast changes and those that don't.

Hugh identified a bunch of existing classes that *could* have
dependents:

Xpp:
Table
Set

be:
Basket
Bert
Snarf
GrandMap

febe:
Hand
Waldo
GateKeeper

optional and probably ignored:
beam
commHandler
Transactions
Session
Tranceiver
Connection

fe:
almost all:  most are Waldos.

Necromancers should probably go away or become an extension of the
dependency mechanism.

Note that we don't have to make these classes use the change protocol
until something requires it.

dean

For the mechanics out there, should the dependents be a set or a bag?