Rewrite capabilities to use interfaces

[zyga]

This large change discards the declarative capability types.
A caps.Capability is now an interface type
A caps.Type is now an interface type.

Concrete capabilities are separate go types (structs). Capability type
knows how to make instances of that type using the caps.Type.Make()
function. To aid in serialization each Capability can now marshal itself
in a way that can be unmarshaled as CapabilityInfo. CapabilityInfo is
generic and simply expresses the public information about any
capability. The caps.Repository.MakeCapFromInfo() function can be used
to make a proper (typed) category.

The advantage of this model is that capabilities are self-contained
types with arbitrary code (not declarations) where appropriate.

[niemeyer]

I'm afraid I don't really understand what this buys us. The purported advantage was already the case.. capabilities were already self-contained, and we already had a clear place to put their custom logic, as we discussed on Monday (the capability type is the place for custom logic, and the thing we had with an interface already in the prior model). With this change we have both the capability and the capability type with custom interfaces and custom implementations, and we've grown up yet another type as CapabilityInfo to play the role that Capability was playing before. Why? What are we gaining for all the extra logic?

Remember the conversation we had on Monday? The goal was to move towards having something working, and to do steps towards having the demo in place. We don't seem to be any closer to that. I'm getting concerned about our ability to deliver useful functionality.

[niemeyer]

Side note: it's Jan 13th.. the sprint ended Dec 12th. It's been one month, and the demo still doesn't work.

[niemeyer]

Let's please have a call to discuss next steps...