Clean up Client API

[kegsay]

It has grown organically so we could test JS/Rust SDK. It's now time to think about the API more before we open it up to everyone.

Thoughts on each part of the API:

• ClientCreationOpts : Addition of extra options in Add ClientCreationOpts.ExtraOpts and move rust specific options to it #144 keeps it extensible. We should cut down on as many fields as possible.
• Must... variants: Remove them and decorate the Client API in tests with Must variants. It's crazy that impls need to implement MustStartSyncing AND StartSyncing, when the caller can just do the err != nil check on their end. Split the Client API in two #146
• Event: re-check rust SDK and try to make it match the wire format for events as much as possible.
• GetNotification: it's useful as other SDKs have push-notification-like code path, but it's very rust SDK specific currently.

RPC-wise:

• RequestOwnUserVerification and ListenForVerificationRequests: we need to implement them. Can probably poll like we do with the waiters?
• Check RPC-only functions for sanity:
  • Server.WaiterStart
  • Server.WaiterPoll

Probably worth having a version handshake initially along with the port (e.g 56434 v1). If we don't, we may have missing RPC functions or missing fields etc. This means we need to document the RPC API. Can we automate it?

[kegsay]

Once these points are done, we should be able to swap entirely to RPC clients for every test. Check the perf hit, and if it's small then do it as that is preferable to having the current embedded vs RPC mess. This would then close #71

[kegsay]

We would probably need to expose a way to say "use binary X for rust" and "use binary Y for js".