Adds destructors to cleanup unreferenced capabilities

When the python object associated with a given capability is garbage collected
(i.e. there are no more references to it), the object will call capnet
to delete the associated capability. Except for flows. Often times,
flows should persist, even after python-level references are lost. They
must be manually managed.

This is a case I didn't consider. I'm not sure about that. I think it's definitely not correct to make the user manually garbage-collect their capabilities. A) because we use a lot of capabilities in the workflows, and B) because it's just a very un-python interface.

Maybe there's a way to preserve this behavior without killing all capabilities when the agent disconnects? Seems kinda gross, so I'm not sure.

> What about workflow agent disconnects?
This is a case I didn't consider. I'm not sure about that. I think it's definitely *not* correct to make the user manually garbage-collect their capabilities. A) because we use a lot of capabilities in the workflows, and B) because it's just a very un-python interface.
Maybe there's a way to preserve this behavior without killing all capabilities when the agent disconnects? Seems kinda gross, so I'm not sure.

For now, I'd be happy to resolve it by simply passing a Context or Config object into Protocol() that would expose config bits. Then this auto-delete style could remain the default; but it could be disabled if necessary. Obviously right now there can only be one Protocol() per port, but if we ever had a different Transport you could imagine more than one instance.

For now, I'd be happy to resolve it by simply passing a `Context` or `Config` object into `Protocol()` that would expose config bits. Then this auto-delete style could remain the default; but it could be disabled if necessary. Obviously right now there can only be one `Protocol()` per port, but if we ever had a different `Transport` you could imagine more than one instance.