Consider observer-based `Delegate` traits

Currently setting up `Delegate` traits (and the related `DelegatesTo` and `PrototypedFrom`) is very expensive in terms of time - not just for setting up dynamic listeners, but also because trait change events on the `Listener` objects get fired during initialization. Additionally, we would like to remove `Listener`-based traits behaviour and replace it with `Observer`-based traits.

Because `Delegate` objects expect a listener-style expression, we can't just replace the internals of `Delegate` to use observers without risking breaking 3rd-party code. However a way forward could happen similarly to the way that `Property` traits were advanced:

- either:
- add a new parameter `observe` which can be given an observer expression and make the `delegate` argument optional
- or add a `use_observers` flag defaulting to `False` (or similar) to tell whether `delegate` holds an observer expression
- when setting up, if we don't have an observer expression, use the existing codepath
- create a new codepath for observer-based delegates (it will likely look a lot like observer-based properties, and may be able to share code)
- add a codepath to `trait_added_changed` to support observer-based delegation there
- add a codepath in ctraits.c to call an appropriate method instead of `_remove_trait_delegate_listener` when using `PrototypedFrom`/`modify=False`.

There may be a few other places that modification is needed.