Improve DebugInfo source provenance

[serenity4]

This PR accomplishes better DebugInfo tracing via the following changes:

• The insertion of DebugInfo was changed to be on top of other DebugInfo nodes. This notably allows Add codegen option to associate debuginfo with statement number at a particular stage #39 to retain source information.
• @insert_node_here uses its __source__ implicit macro argument to insert additional DebugInfo information, if the insert_stmt_debuginfo setting is enabled.
• Similarly, replace_call! now takes a source and a settings struct to conditionally insert additional DebugInfo.
• Most insert_node_here! calls were converted to the macro form, @insert_node_here. Those that remain in function form use additional source and settings arguments to indicate provenance for optional DebugInfo.
• slotnames information has been added to the ODE/DAE RHS codegen, and to the factory IR.

I also included a refactor for the naming of locals in the ODE codegen while I was at it; see 676875a. I find it clearer, but if it's just me I am open to reverting that.

To do:

• See if we can turn the multiple "macro expansion" annotations into something more readable.
• Address the crash observed in test/ipo.jl.

[serenity4]

For reference, this is what we now get:

Looking into the chained macro expansion lines, what we'd need to have them show in a nicer way (i.e., nesting properly instead of accumulating on the same line) is to extract a method (any method) of the function updating/inserting a statement. For example, statement %2 in the screenshot is traced to tearing/schedule.jl:49, which is ir_mul_const!, so we'd need something like first(methods(ir_mul_const!)) and use that in debuginfo.def. This is what proper nesting would look like (don't mind the obviously wrong method/lines):

as opposed to e.g. %4 in the first screenshot where certain sources accumulate on the same line.

However, I don't think we have a non-intrusive way to do this, so I don't think that'd be worth it in the end and the current state seems largely good enough.

[serenity4]

That is a bit of a hack, though calling show is kind of UB from generated functions. I'm only allowing UndefVarError here which are currently caused by binding lookups in certain cases, but it's not impossible that we later discover that other exceptions may be thrown.

[serenity4]

I made source location slightly more precise for ir_mul_const!/ir_add!, and used the refactoring opportunity to rename @insert_node_here to @insert_instruction_here in the last batch of commits.

I'm thinking of removing the @insert_instruction_here macro form entirely to rely on the function insert_instruction_here!, and define one to create instructions, like @inst (a + b)::Float64, which was the main processing done there anyways. Source will then be attached manually via @__SOURCE__ instead of the macro argument __source__. Review can wait a little bit more until I get that change in.

[serenity4]

I'm thinking of removing the @insert_instruction_here macro form entirely to rely on the function insert_instruction_here!

In the end, I decided to keep the macro and use it in with a standard :call syntax. I find that the added verbosity of the alternatives didn't help with clarity that much, though that's entirely subjective. @topolarity I hope you will find the macro usage bearable 👀

This PR is ready for review whenever you like @Keno