Add tests to demonstrate behaviour when mutating extension point directly

[kitchoi]

This PR add tests to demonstrate the contradiction / challenge for solving #291.

In summary:

• ExtensionPoint is like a property. Its value is recomputed on every access of the attribute.
• Mutating the extension point list directly has no effects on the registry, nor will it fire events for the x_items listener
• Being able to listen to x_items is misleading.

Details:
When someone defines an ExtensionPoint in their class like this:

class MyApplication(Application):
    x = ExtensionPoint(List, id="my.extension")

One can listen to changes to x_items, like this:

    @on_trait_change("x_items")
    def handle(self):
        ....

This makes developers believe that x is like a persisted list and they can listen to its mutation.
But that is in fact not true. The value of the extension point is computed every time when the attribute is accessed. It is more like a Property. For it is ephemeral, one cannot listen to the mutation on the list that is refreshed on every access.

In fact, when one listens to x_items in the context of extension points, what they are listening to is changes from the contributors of that extension point, and what they want is the specific details on what have been removed or added to the extension point. Envisage could well have called that x_contribution_changed, or x_whatever_event. The naming of x_items is unfortunate as it clashes with the meaning of mutating a persisted list in on_trait_change mini-language.

[aaronayres35]

Tests LGTM! I believe I still need to a do a bit of study on the issues/PRs you have opened and the code itself to fully understand what/why things are happening in this way.

The tests are very useful though at demonstrating the behavior! thank you!

[aaronayres35]

Test LGTM, behavior is still a litte confusing to me. So effectively this line does nothing?

[kitchoi]

Yep. Technically, this line does append to a list, but that list is not kept anywhere and is thrown away.