Canonicalize names of nested functions by keeping a more fine grained counter -- per (module, method name) pair

[d-netto]

As mentioned in #53716, we've been noticing that precompile statements lists from one version of our codebase often don't apply cleanly in a slightly different version.

That's because a lot of nested and anonymous function names have a global numeric suffix which is incremented every time a new name is generated, and these numeric suffixes are not very stable across codebase changes.

To solve this, this PR makes the numeric suffixes a bit more fine grained: every pair of (module, top-level/outermost function name) will have its own counter, which should make nested function names a bit more stable across different versions.

This PR applies @JeffBezanson's idea of making the symbol name changes directly in current-julia-module-counter.

Here is an example:

julia> function foo(x)
           function bar(y)
               return x + y
           end
       end
foo (generic function with 1 method)

julia> f = foo(42)
(::var"#bar#foo##0"{Int64}) (generic function with 1 method)

[d-netto]

Serialization doesn't seem happy with this PR...

[vtjnash]

I think you need to keep this mostly inside flisp (particularly parsed_method_stack). I also don't think the module name has much value in being mangled into it. Making the name be a combination of the containing method + index into that method name seems somewhat prettier, I also don't see how that canonicalizes names any more than before. I don't really like that this adds more hidden and secret global statefulness to the lowering algorithm as well.

[kpamnany]

I think you need to keep this mostly inside flisp (particularly parsed_method_stack). I also don't think the module name has much value in being mangled into it. Making the name be a combination of the containing method + index into that method name seems somewhat prettier, I also don't see how that canonicalizes names any more than before. I don't really like that this adds more hidden and secret global statefulness to the lowering algorithm as well.

@vtjnash: to reiterate, our goal here is to improve the consistency of the names generated for these functions. Currently, adding one lambda inside one function can change the generated names of all nested functions across all modules in our application, which means that a number of the precompile statements emitted via --trace-compile by the previous version will fail on the new version.

This PR essentially makes the generated names/numbers independent of changes to other modules+functions.

Do you see any other way for us to accomplish this or does this explanation address your objection(s)?

[d-netto]

across all modules

Wrong since the counter is already per-module (grep for fl_current_module_counter).

Still, as mentioned above, the proposed change would ensure that adding a nested function doesn't perturb the name generation in literally every numeric suffixed name in a given module.

[kpamnany]

We've tested this change by exercising it through compilation warmup in our application. Without this, we saw roughly 53% warmup effectiveness when upgrading versions. With this, we're seeing 68% warmup effectiveness. Although this comparison is not quite apples-to-apples, there is a notable reduction in precompile evaluation failures across versions and warmed up performance has improved. So this is a good change for us.

[kpamnany]

Ran more tests to verify the gains from this and have verified that this is a positive change for us.

Any objections to merging @JeffBezanson?

[topolarity]

I agree with @vtjnash that I don't like how this creates an implicit state internal to ast.c that has to be considered together with the program flow through the flisp for correct-ness.

Is it not possible instead to pass a relevant stack of "parent" functions through cl-convert and then into current-julia-module-counter, so that all of this is handled explicitly in the flisp?