Changing Client Connection semantics

This has a bunch of small, low-level changes originating from #44 .

* Fixes #44, which was stemming from the fact that connect could be called multiple times on a client.
* Service clients now automatically connect when bound to a worker.  This means there is no longer a `connect` method for clients.  However there is one major caveat here.  When created using the default constructor, this auto-connect doesn't happen because the handler is not automatically bound to a worker.  This means if you create a service client manually (such as `new ServiceClient(config, codec)`), you have to call `bind` on the worker to bind the client to that worker.  But the connection is automatic when the constructor with the worker is used, or when creating a client in the DSL using `clientFor`, or when using the new `BindAndConnectWorkerItem` IOCommand.
* No more `BindableWorkerItem`.  This was to prevent users from accidentally trying to bind ConnectionHandlers, which would technically work but never actually establish a connection.  This is still sometimes the case (not with ServiceClient), but we have a new BindAndConnectWorkItem which does establish an outgoing connection.
* `BindWorkerItem` now accepts a `WorkerItem` instead of a `() => WorkerItem`.  This is largely because the `onBind` callback now serves as the in-thread initialization point instead of the constructor.

I will probably be adding a few more tests before merging, but I figured I throw this out there now.
yeah, the connect method no longer exists.  I have other tests incoming that deal with rebinding worker items.