Optimization: Remove constraints on arrow firing

[nathanwbrei]

Previously, the scheduler would assign arrows to workers with only a hint as to whether they could actually fire. Firing logic was complex, attempting to pop some number of events for each input queue, reserving space for a predetermined number of events on each output queue, and in case fewer events proved poppable/reservable than desired, reverting the operation. This led to two problems:

1. Locks needed to be acquired for each input and output queue both before firing and after, whether firing was successful or not.

2. If the preconditions were not met, the worker would retry firing, but with a delay. Since the worker has no indication of whether the arrow was about to become fire-able or not, this leads to unnecessary waiting in places where no work is available, when work is available elsewhere. Conversely, when an event source is delayed due to having no data ready on a socket, or due to a barrier event, this leads to the scheduler rapidly hammering the event source when a more appropriate action would be to wait.

This PR refactors JArrow in order to address issue (1) and clear the way for addressing issue (2). It does the following:

• Making reservations on output queues is no longer necessary, as queues are now sized to always hold max_inflight_events items.

• Arrows have been refactored to support a much simpler (and easier to achieve) trigger. In order to successfully execute, each arrow needs exactly one event from one predetermined queue, (plus an optional delay parameter for polling sockets and barrier events). This should decrease the number of spurious retries in more complex processing topologies, and make debugging, inspection, visualization, and timeout logic much cleaner.

• The very general JArrow::Place and JArrow::Data machinery (which was introduced in order to keep the now-removed pull/reserve/revert logic tractable) has been replaced by a much simpler JArrow::Port that removes a few virtual function calls and makes it possible to generically wire arbitrary JArrows together via a config parameter.