[ESI Runtime] Read ports now invoke callbacks

[teqdruid]

We've switched from a polling 'pull' method to a callback-based 'push'
mechanism for read ports. Polling (via std::futures) is built on top of
the push mechanism.

The read-ordering problem has also been fixed by using std::futures
exclusively for polling schemes. They also allow for poll-wait-notify
schemes without any changes on our part.

[mortbopet]

AFAICT this solves the multiple-readers problem, but doesn't solve the function service call problem.

The following code still does not guarantee that calls to a function is ordered wrt. the order of which the argument port was called

circt/lib/Dialect/ESI/runtime/cpp/lib/Services.cpp

Lines 118 to 119 in 18d2872

	arg.write(argData);
	return result.readAsync();

I.e. the following interleaving of two calls C1 and C2 is possible

C1 arg.write
C2 arg.write
C2 result.readAsync
C1 result.readAsync

So there must be a lock added to FuncService::Function::call to ensure that readAsync is always called for function call n before function call n+1 occurs.

[teqdruid]

@mortbopet: if you're not blocked on this, I'm actually gonna finish the gRPC conversion first so that I don't have to screw around with the capnp backend to adapt it to the changes we discussed.

[teqdruid]

I think switching to callbacks made things more elegant.

[mortbopet]

With these split modes, and different modes having different member variables associated with them, i'd personally split those into two separate ReadChannelPort-derived classes to avoid any confusion/misuse/leak between the two API modes.

[teqdruid]

This is something I considered. The problem is that these channel ports are constructed when the system gets built from the manifest, not when the user locates them. So the user doesn't have the chance to specify the type before getting the reference to them.