Refactor caching of data products

[knoepfel]

phlex currently caches data products/stores for a few node types (e.g. transforms, observers). This caching should be factored out of those nodes themselves and placed in a dedicated node for situations where a cached data product is needed (e.g. an algorithm that uses a data product from both the "job" and the "spill").

[knoepfel]

Introducing repeaters

The following workflow shows a node consume that uses a data product $p$ from each run (indexed by $i$), and a data product $x$ from each spill in each run, which is indexed by the pair $(i, j)$.

For example, in run 4, the data-product $p_4$ is paired with each data product $x_{4,j}$ when presented to the consume node. It is difficult in oneTBB's flow graph to "repeat" the $p_4$ data product when paired with another data product that is presented to consume at a different cadence.

One solution, however, is to use a "repeater" node, which is a kind of unfold node. Because an unfold node generates one or more data products per input data product, the repeater node simply emits the same data product multiple times until an end token is received (checking that the right number of repetitions has occurred).

The following shows a data-flow graph that supports repeater nodes:

Note that 2 additional nodes are created (the repeater itself, and a node for sending the end token), and extra edges are added so that the repeater knows how often it should repeat the data product (the connection between $I(spill)$ and the $iter$ port).

An implementation of this scheme is exercised in #118.