[Chandler-dev] onValueChanged() replaced by 'afterChange' attribute aspect

[Andi Vajda]

The onValueChanged() method was invoked on an item instance after any Chandler 
attribute change. This was too big a hammer and is now replaced by something 
more fine grained, a new 'afterChange' attribute aspect that may list one or 
more names of methods to invoke on an item instance after the corresponding 
attribute(s) change.

  - the protocol of an 'afterChange' method is the same as the former
    onValueChanged():
      def onBodyChanged(self, attrName):
          ...
    where 'attrName' is the name of the attribute that changed. Having this
    argument makes it possible to use the same method for several attributes if
    desired.

  - an 'afterChange' method is invoked on an item instance only if that method
    is defined. It is not an error to specify the name of an undefined method.
    The reason for this is that attributes are inherited (or even shared among
    unrelated kinds) and the 'afterChange' attribute aspect method names are
    stored on the attribute schema item.

  - as stated above, the 'afterChange' attribute aspect expects a list of
    method names. No code should be made to depend on the order of names in
    that list for the order of method invocation, which may be random.

  - I added a kludge to the schema API to update existing (usually inherited)
    attributes with an 'afterChange' aspect value:
       schema.afterChange(attrName=['method', 'names'])
    until Phillip replaces this with a new decorator or somesuch.
    If the attribute already has an 'afterChange' aspect, schema.afterChange()
    appends the method name(s) to the existing value, removing potential
    duplicates.

  - to set an 'afterChange' attribute aspect, the attribute has to be
    defined for that kind (or class) or inherited. With onValueChanged() it was
    possible to write code reacting to changes for non-existing attributes. For
    example, CalendarEventMixin's onValueChanged() method (now called
    onEventChanged) was reacting to changes in a bunch of attributes
    among which 'body' and 'lastModified' which are nowhere defined in its
    kind/class hierarchy. This was working because item instances of
    CalendarEventMixin are also ultimately instances of kinds/classes where
    these attributes are defined.
    With the 'afterChange' aspect, this trick is no longer possible. The
    schema.afterChange() API emits a warning into chandler.log accordingly.

I fixed up all Chandler code using onValueChanged() to use the new 
'afterChange' attribute aspect instead. I renamed the onValueChanged() methods 
to use more relevant names but they sure can be renamed again...

Andi..