Don't proxy/change request.ID in looping transport layer unless necessary

[ryanschneider]

I mentioned this as a comment in #18, but ideally we don't change the outgoing request ID in the websocket/IPC layer unless strictly necessary. However, to do this either the clients need to ensure that each concurrent request has a unique ID, or we need to serialize requests w/ the same ID, which requires a fair amount more logic in loop.go.

A good compromise after #7 is fixed is that if the context has no request ID, then generate a unique one, if the context has an ID, first see if there's already a request w/ that ID in flight, in which case we need to wait for that previous request to complete before dispatching the next one.

Thus, by default, the client would behave as it does now: each request gets it's own auto-generated unique ID. If a client wants to both control IDs and dispatch multiple requests concurrently, they need to supply unique IDs to each request, which seems like a reasonable trade-off.