[compiler] Code-Generated TableIntervalJoin(..., product = true)

[ehigham]

Add staged code generation capabilities by lowering to and emitting
StreamLeftIntervalJoin.
The EmitStream rule for this node uses a code-generated min heap* of
intervals that contain the current key in the left stream, ordered by
right endpoint.
The row type of the join result is the left row with an array of values**
from the right table, ordered by their associated interval's right endpoint.

Note that this implementation is by no means optimised. There are a number of
opportunities that I'd like to consider in subsequent changes, including:

• Laziness in restoring the heap property on push/pop from heap.
• Not deep-copying elements of the right stream when no explicit memory
  management per element is required.

* This min heap is code generated instead of using an off-the-shelf
implementation as:

• we dont yet to have a mapping from SType to a java class or interface to
  parameterise the heap with
• not obvious how to handle region memory management in an existing solution

** The value is a row with the key fields omitted.

Additional Changes:

• Make this an explicit argument to CodeBuilder.invoke()
  • Gives us control which object we're dispatching on.
  • Useful for generating more self-contained classes
  • Previously assumed all methods were defined in the same class.
• Removed referenceGenomes from ExecuteContext
  • Delegate to Backend; in practice these come from the backend anyway.
  • These were being populated from the backend object
  • Backend is mutable meaning we can add/remove fake genomes for testing

[patrick-schultz]

Really great work! Thanks for pushing on the infrastucture for generating multiple classes, I think that's super valuable. I have some comments, but they're mostly small things.

[patrick-schultz]

Should do this check in CodeBuilder.invoke[Code] too.

[ehigham]

All the type-checking was done in EmitCodeBuilder. Perhaps some generic version should be in CodeBuilderLike.
I don't think this is essential for this change. We can revist this later for a proper tidy-up (which perhaps would be nice to do at some point).

[ehigham]

OK, I tried to add an assert. This caused way too many failures. In order to get this to work properly I think we need to track more information about class hierarchy in the TypeInfo object.

This code fails:

val F = FunctionBuilder[Int]("F")
...
val a = cb.newLocal("a", Code.newInstance(F.cb, F.cb.ctor, FastSeq())
cb.invoke(F.mb, a) // typecheck failure

a has type LocalRef[AsmFunction0[Int]] because the compiler infers it from the FunctionBilder (type FunctionBuilder[AsmFunction0[Int]]). The TypeInfo on F, however, is L_C1F;, which is not the same as the TypeInfo on a: Lis/hail/asm4s/AsmFunction0;

Worthwhile doing, but I think it may be a larger change to get this to work properly.

[ehigham]

Thank you for your review, Patrick - it has significantly improved this PR.

addressed feedback

[patrick-schultz]

nice work!