Concurrency models to support with native language bindings

Nobody has claimed this yet.

Opening this issue to continue the discussion we started regarding what concurrency models that should be supported when targeting language level bindings.

### Asynchronous Model
Concurrency handled on the Go client side. Async calls from Java/Python/C etc that require a response are tracked with an id. There are two ways we could handle this:
1) Java/Python/C could poll the Go client until the matching response id is returned
2) Java/Python/C could provide a function pointer and the Go client could issue a callback when the response is ready.

> I prefer option 2 here

### Synchronous Model
There might be cases where we want to provide a synchronous mode of interaction. This might be useful for simulations where we want things to happen during each timestep for the purpose of research and reporting the health of the network given different simulated pathological scenarios.

> Just a thought. I am curious what you guys think

The issue names no files, tests, or concrete entry points; begin by locating the Go daemon's existing native-language binding API and request/response handling. The concurrency model still needs agreement on polling versus callbacks and whether synchronous operation is required, after which the agreed behavior can be implemented and tested.

Written by the indexing model from the issue text.