Adding element property for signal names

Testing, for it too, though just for Element.
Adding overridden tests for class signals
Adding skeleton for communication

This is currently set up for establishing communication from the
element’s configuration object.
Processing signals, with some error handling

If a user provides a signal target, we currently assume it to be in
element notation: <element_id>.func_name.

Reasonable errors are handled (element not found, func_name not found,
etc).
Testing visibility is correctly set

Visibility should be correctly set by the communicator we have
connected.
Refactoring signal targetting notation

Signal targeting notation could either indicate a python package or an
Element by ID.
Using new Element notation
Updating ID for debugging
Allowing python functions to be callbacks

If the user provides a python function as a callback target, it should
be observed, without any extra importing necessary.
Comments and TODOs
Initializing communications when building by json
Setting up communication
Emitting a new signal when interactivity changes
Tracking element interactivity in the GUI core
Adding new signal to tests

And cleaning up a test that was a duplicate of a superclass.
Removing debug logging
Adding element communication setup

I had previously forgotten to set up element communication when adding
an element programmatically.
Adding debug info to signal config step
Adding set_enabled to GUI layer
Adding 'element satisfaction' functionality

Element satisfaction determines when an element should be enabled or
disabled, per the IUI definition of the ‘enabledBy’ attribute.