Identify capabilities with pairs (snap, cap)

[zyga]

This patch makes capability name non-unique. Instead the pair (snap
name, capability name) is now the unique way to refer to capabilities in
the system.

This change is motivated by the need to resolve conflicts when more than
one snap wants to create a capability with a given name. Using the pair
makes the problem go away.

[niemeyer]

They keying by (snap, capability) at this level of the API feels slightly curious. It's optimizing for a very particular lookup, which will become very fast but that doesn't seem to match many of the interactions we need to put in place soon (caps for a snap, providers, consumers, etc).

Besides that, there's also another issue which is worth some thought: a particular capability is not actually a property of a given snap name, but of a particular revision of that snap name. And we also have the two sides: a provider, and a consumer, and we have the linkage between the two.

Finally, we should think carefully about introducing the concept of a capability id when we already have a capability name which is the identifier we want people to think about. We already have type and name.. having type, name, and id wouldn't help conversations about the topic.

I'll think a bit through this as well. Let's please catch up online.

[zyga]

I've closed this now, the new API that we've brainstormed online will be published soon.