Ticket #194 (new task)

Description

This came out of a discussion on the mailing list. My proposal is to have a configuration parameter named 'extra_services' which contains a dictionary of Service objects implementing arbitrary extra Twisted services. Brian wrote:

The cextra_services? hook would be a cleaner approach. It could be just like cstatus? except that it wouldn't assert that the object implements IStatusReceiver first.. it would just accept anything. The only wrinkle is that we should decide whether or not cextra_services? ought to do the same compare-before-replacing trick that the rest of the config file does, to avoid restarting a service that hasn't been modified.

My thinking is that we go one-better on the consumeTheSoulOfYourPredecessor/..Successor methods, and implement a mergeWithExisting method that *returns* the desired object -- either the "new" object or the "old" or, for whatever reason, a completely new object. The default implementation of this method would be 'return self'. Services which want to keep running would push any new configuration into the existing object, then return that object.

The reload code would be responsible for recognizing when mergeWithExisting returned a distinct object from the existing, and re-adjusting the service parents appropriately in that case (divorcing the old object, and calling setParent on the new object).