use specialized code when compiling opaque closure expressions

[JeffBezanson]

Before, we compiled the unoptimized IR of the function on this code path; with this we instead use the optimized version that we probably created when optimizing the enclosing function.

before:

julia> using Base.Experimental: @opaque

julia> ff() = @opaque (n::Int)->(s=0; for i = 1:n; s+= i; end; s)
ff (generic function with 1 method)

julia> g = ff();

julia> @time g(1000000)
  0.097487 seconds (4.00 M allocations: 76.278 MiB, 12.50% gc time)

after:

julia> @time g(1000000)
  0.000004 seconds (1 allocation: 16 bytes)

This also normalizes the code a bit by using jl_specializations_get_linfo instead of manually allocating a MethodInstance.

The next step is to invoke the optimizer and compiler from jl_new_opaque_closure so we can do this at run time as well. After that, it would also be nice to avoid recursive codegen (calling emit_function), and make this work more like other call sites.

[JeffBezanson]

Updated to restore the specptr field, and also added run-time specialization support. Not 100% sure I got the calling convention stuff right.

[vtjnash]

@Keno may need to review and comment. I thought this function returns the same method-instance each time for a given sigtype, but that the ability to optimize an OC is depending on each copy of the OC potentially having different code depending on where it was initially allocated.

[Keno]

Right, we don't currently have the code to that in the optimizer thought. I figured we would do that by allocating a non-cached MethodInstance in the optimizer and putting that in there with the appropriate typed IR. I think that would make this OK, because this specialization cache is then the version that doesn't have any capture optimization done to it.

[JeffBezanson]

Fixed the const_return case, plus put in a very temporary hack to make varargs work again. I'm working on a more thorough refactoring that will allow us to use only the isva flag on the Method, which will make OpaqueClosure much easier to work with internally.

[vtjnash]

We have existing front end support for syntactic varargs with variable-derived bounds, but I think Keno had a reason for choosing to do it this way instead?

[JeffBezanson]

We discussed it --- whether the signature is vararg needs to be determined at runtime, but whether the method code is vararg (i.e. automatically turns its last argument into a tuple) can be static.

[DilumAluthge]

Looks like this PR broke analyzegc. Example log: https://buildkite.com/julialang/julia-master/builds/8670#01c69ec1-5528-44f7-99d5-4136a73d5d3d

/cache/build/default-amdci4-4/julialang/julia-master/src/interpreter.c:728:5: error: Passing non-rooted value as argument to function that may GC [julia.GCChecker]

[DilumAluthge]

@Keno See the analyzegc failure above.

[DilumAluthge]

Just so we don't forget, I went ahead and opened #44147.