rework on src.slottypes and ir.argtypes

[aviatesk]

This commit reworks our handling of (src::CodeInfo).slottypes and (ir::IRCode).argtypes. Currently ir.argtypes contains types for call arguments and local slots even after the SSA conversion (slot2reg), which can be quite confusing. Similarly, src.slot[names|flags|types] contains information about local slots regardless of whether src is optimized or not, even though local slots never appear within src.

With this commit, we resize ir.argtypes so that it only contains information about call arguments after slot2reg, as well as resize src.slot[names|flags|types] after optimization.

This commit removes unnecessary information upon appropriate timings and allows us to use Core.OpaqueClosure(ir::IRCode) constructor for such ir that is retrieved by Base.code_ircode:

let ir = first(only(Base.code_ircode(sin, (Int,))))
    @test Core.OpaqueClosure(ir)(42) == sin(42)
    ir = first(only(Base.code_ircode(sin, (Float64,))))
    @test Core.OpaqueClosure(ir)(42.) == sin(42.)
end

[aviatesk]

@nanosoldier runbenchmarks("inference", vs=":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

[aviatesk]

@nanosoldier runbenchmarks("inference", vs=":master")

[nanosoldier]

Your benchmark job has completed - no performance regressions were detected. A full report can be found here.

[vtjnash]

Is this a new problem?

[aviatesk]

Kind of. Previously we just created ir.argtypes based on the length of ci.slotflags no matter if ci.slotflags contains flags for local variables. That wasn't a problem, because the optimization passes don't care if ir.argtypes contains extra type information (and this is why we have used ci.slottypes as is for ir.argtypes in the main optimization pipeline).

After this commit, this code becomes a bit problematic since we will make additional efforts to make ir.argtypes contain types of call arguments only. Having said that, it's not that problematic usually (because the optimization pipeline doesn't care it currently). It would be problematic if we generate OpaqueClosure with ir created by inflate_ir(ci) with un-inferred ci, which triggers this code path, but it's such a rare case anyway.