A JOIN clause about ramen HOT 6 CLOSED

Now that we have the multiple FROM clause, the scope of this actually reduces to the merge sort.

also we need a criteria to when tuples are too late for integration and need to be rejected (and a count for this).

from ramen.

Closing then, in favor of #12

from ramen.

Actually not quite identical, as the from-multi + sort would buffer the entries in RAM while this JOIN would keep the in-advance tuple in the ringbuffer, thus blocking the producer after a while.
If, that is, we have one ringbuffer per parent in that case.

So proposed changes:

1. allow a JOIN on expr clause
2. if there is such a clause, create one ringbuf per parent and pass them all to the worker
3. change CodeGenLib.aggregate to read from N ringbuffers and, if there is a join clause, merge sort those buffers, assuming they are already sorted.

from ramen.

Added into PRR1 as an acceptable alternative to waiting at the file reader level.

from ramen.

Note: this is actually not a "joint" so let's call this "merge" instead.

from ramen.

We still need:

1. A timeout option (since some sources might be completely dry)
2. ramen_configurator to use this

from ramen.