Support arbitrary client metadata, avoid linear seach in sendCap.

[zenhack]

This solves an issue I discovered where sendCap() does a linear search
on the exports table for each sent capability.

After a long discussion with Louis over matrix, we concluded that adding
a metadata object for clients was the best solution; there's a general
design awkwardness right now where the rpc system needs to be able to
inspect the client in various ways, but Client is defined in the main
package and tries to encapsulate its implementation details. To some
degree we are able to use Brand(), but this gets awkward quickly,
because:

1. ClientHook is an openly implementable interface, so we don't know
   all the posibilities in the rpc code.
2. As I've been working on supporting receiverAnswer, I've found
   pinning down all the implementations I defined in the library that
   need to be worried about is challenging.
3. Some of these implementations aren't even exported, or just return
   nil from Brand().

The Metadata object lets the rpc system manage the bookkeeping
information independently of the internals of a client.

I expect to use this for more in the future, but for now this lets
us avoid the linear search by just storing the export id for each
connection in the client's metadata.

[lthibault]

Approving this because it looks correct. Nevertheless, I feel moderately strongly that the two readability issues I've flagged should be addressed before merging. Your call.

[lthibault]

Could this check in sendCap be refactored to use isLocalClient from #212 ?

That would be a huge readability win. The above snippet is quite jarring every time I look at it, despite the fact that the domain logic it represents is dead-simple.

[zenhack]

Could this check in sendCap be refactored to use isLocalClient from #212 ?

I assume you meant to link to a specific line? The link just points to the whole diff, so I'm not sure which check you mean.

[lthibault]

Looks like it was merged, so no longer appearing in the diff: https://github.com/capnproto/go-capnproto2/blob/8c878e053da7da0aa3d7c46f9c60c1338efaa84a/rpc/export.go#L88-L93

However, I just saw that we actually use the concrete *importClient, so never mind.

[lthibault]

Cheers, much nicer to look at :)