[JuliaLowering] Implement static parameter capture

[mlechu]

Static parameter capture is (as far as I know) the last non-trivial, non-performance piece of
JuliaLowering that doesn't match flisp yet. I kind of understand why it was
left unimplemented. In flisp lowering:

• Scope resolution for static parameters in method signatures is more-or-less
  done in desugaring
  • This is buggy; see Disallow reading from underscore sparams in function arg decls #60626
• We need two new variables for every sparam: the sparam usable in the lambda
  body, and the method-signature typevar at top level
• Capturing an sparam into an inner method signature means we need to add
  somthing to the method definition's typevar list
• Capturing an sparam into an inner lambda body means we need to add to both the
  inner lambda's sparams as well as the inner method definition's typevar list
• Defining and instantiating the closure type also requires knowing what static
  parameters to feed into the apply_type call
• Captures are only known after variable analysis but need to change
  desugaring's decisions, so:
  • The typevar list is constructed in desugaring, then the core svec
    expression is re-constructed to contain sparam captures in closure
    conversion
  • analyze-vars-lambda mutates the lambda's sparam list

Static param capture into the lambda body in JuliaLowering happens to work today
because it's treated the same as a never-boxed local, so it's just a struct
field. I assumed this might cause inference issues, but admittedly didn't check.
The main issue is that capture into signatures doesn't work
(JuliaLang/JuliaLowering.jl#140).

This PR:

• Don't do the flisp renaming-sparams-early step, since it just makes the hard
  parts of this harder.
• Change the method form out of desugaring to be (method argtype_svec lambda) and fully construct the svec after its contents are known
• Change the method_defs form to be (method_defs id typevar_list body),
  because typevar_list should always precede lifted stuff in closure conversion,
  and because special resolution needs to happen when each (typevar a b) gets
  resolved (resolve b first, then declare a).
  • This is kind of a hack, but I didn't want deeply-nested scope blocks. These
    were previously declared as locals, which had the wrong scope resolution
    (they could all see each other), and this was a pkgeval problem.
• Add new binding kind :typevar. This behaves like a local up until
  before linearization, and more like an ssavalue after that.
• In scope resolution, we collect the mapping from static parameter to typevar,
  so that inner method signatures may resolve successfully (and even re-use the
  original typevar)

This change also implements "underscore sparams are readable" #60626 and ports
#57928 (sparam capture in opaque closure is more like capture of locals). It
does not fix the pkgeval bug @topolarity reported to me with same-named
functions that require different closure types.

I've also added a cleaned-up Claude fix for typevars that depend on each other
in their bounds. Not sure if it's the best way of doing this. There's an easy
way out if this approach doesn't work (flisp just creates typevars <:Any in
closures).

The real change isn't as big as the diff implies, it just changes the closure
type creation near the beginning of the IR in many tests, so ends up changing a
lot of IR numbering.

[topolarity]

Counter-examples, courtesy of you-know-who:

# 1. Bound references the loop variable → UndefVarError at load time
for x in (Int, Float64)
    global f
    f(y::T) where {T<:x} = T
end
# flisp: works, defines both methods.  This PR: UndefVarError(:x)

# 2. Bound references a global reassigned in the loop → silently stale bound
global b = Int
for i in 1:2
    global g, b
    g(y::T) where {T<:b} = (i, T)
    b = Float64
end
g(1.5)   # flisp: (2, Float64).  This PR: MethodError (bound stuck at Int)

seems that TypeVars can end up hoisted even when the Method def they accompany is not

[topolarity]

A few corners to solve, but largely this change looks quite good to me.

Nice that we were able to recover quite a bit of parity with flisp AFAICT, despite the difference in implementation.

[topolarity]

semi-exotic case:

global TE = Int
fE(x, y=((z::TE)->z)) where TE = y
fE(1.)(2)

prints 2 in flisp

[mlechu]

Changed to match flisp, though I think this behaviour probably isn't what we want. Left a comment above the test case.

[topolarity]

Agree w.r.t. questionable-ness

[topolarity]

Nice work as usual @mlechu