Implement synchronous "data" endpoint

[Joe Stubbs]

By combining the aliases and results endpoint features, we have two of the primary building blocks for the proposed "adapters" capability. Even though it has essentially been implemented in tooling, it occurs to me that a final ingredient that would be of independent interest and would possibly allow us to call the adapters capability "feature complete" would be a synchronous data endpoint. The idea would be to provide a convenience endpoint like this:
/actors/v2/{actor_id}/data
(equivalently, /actors/v2/{alias}/data)
that would synchronously:

1. send a message to an actor based on the request (see details below)
2. subscribe to the execution's results queue and respond to the request by returning the result once ready.

This endpoint would provide a final ingredient for adapters since the request could contain "search" parameters representing a query to an adapter. Viewed in that way, it would make sense semantically for the endpoint to accept GET and URL query parameters.

However, the endpoint should also be useful for "compute oriented" actors since, by combining 1) and 2) into a synchronous call, it will eliminate poling on the client side, and should ultimately be much more efficient since it does not have to wait for the execution to be "finalized" by the worker (i.e., the various clean up tasks done at the end of an execution by the worker). With this use case in mind, to make the endpoint more useful, I think it could also accept POST, including octet stream content type bodies. This would make the functionality equivalent to the /messages endpoint.

@mwvaughn - I'd really like to hear you thoughts on this idea. In particular,

1. what do you think about the endpoint name itself, (data), vs some we had considered in the past (e.g., /search). To me, /data seems more appropriate for handling other use cases outside of adapters.
2. what do you think about allowing GET and POST?