Fix some invalidations during Julia's bootstrap

[timholy]

This cuts the total number of invalidations that occur during Julia's build process approximately in half. It may knock about 2% off Julia's build time, though that's about in the noise so I am not sure. Here was one run on master:

Sysimage built. Summary:
Total ───────  52.165692 seconds 
Base: ───────  21.758738 seconds 41.7108%
Stdlibs: ────  30.406945 seconds 58.2892%
    JULIA usr/lib/julia/sys-o.a
Generating precompile statements... 30/30
Executing precompile statements... 1870/1877
Precompilation complete. Summary:
Total ───────  84.620999 seconds
Generation ──  58.195211 seconds 68.7716%
Execution ───  26.425789 seconds 31.2284%

and here were two runs on this(*caveat: also using #35877) branch:

Sysimage built. Summary:
Total ───────  50.963781 seconds 
Base: ───────  20.885574 seconds 40.9812%
Stdlibs: ────  30.078193 seconds 59.0188%
    JULIA usr/lib/julia/sys-o.a
Generating precompile statements... 30/30
Executing precompile statements... 1858/1865
Precompilation complete. Summary:
Total ───────  85.445948 seconds
Generation ──  59.581762 seconds 69.7304%
Execution ───  25.864185 seconds 30.2696%

Sysimage built. Summary:
Total ───────  49.995934 seconds 
Base: ───────  20.612026 seconds 41.2274%
Stdlibs: ────  29.383900 seconds 58.7726%
    JULIA usr/lib/julia/sys-o.a
Generating precompile statements... 30/30
Executing precompile statements... 1858/1865
Precompilation complete. Summary:
Total ───────  85.556325 seconds
Generation ──  59.087194 seconds 69.0623%
Execution ───  26.469131 seconds 30.9377%

Interestingly, both were about a second longer on generating the precompile statements, reducing or eliminating the total advantage. I don't know whether that's systematic. (With fewer to build, you might expect it to be faster, maybe?)

The remaining invalidations fit a couple of patterns:

• lots of invalidations from loading reducedim.jl, which specialize methods already in active use from reduce.jl
• lots of promote_rule invalidations due to specializing the fallbacks. None of these have large cascades of consequences, however.
• a couple of invalidations, one with a consequence of quite a few MethodInstances (~80? I don't really remember), from code that might call a function before it has any methods defined (result: they mt-invalidate themselves):
  • with_output_color gets used by the show method in cmd.jl which gets used by Base.FileRedirect via the logging framework
  • fill! isn't defined until well after its first potential use by show(io::IO, x::Type), via the vcat call

While trying to understand the with_output_color phenomenon I added a @nospecialize, this is a bonus but it seems reasonable.

I'm happy to back out some of these if folks prefer, just let me know. I was basically going down the list, but none of these are game-changing so we can afford to drop some.

[timholy]

Related: #36411 (that was not tested along with this, and the combination will get rid of a few more besides being more correct)

[JeffBezanson]

This seems very strange --- AFAICT we already know that project is a String here, so I don't know why this would be. We should investigate.

[JeffBezanson]

Got it --- it's due to recursion via load_path_expand. The types get narrowed later, but the edges added before the recursion resolved are still there.

[JeffBezanson]

I wouldn't expect this to do anything --- arg has a declared type, plus this function already only reads the variable.

[timholy]

And it doesn't help, it's still boxed. I meant to back that part out, will do it now. s and i are now unboxed.

[timholy]

I should have also given absolute numbers: after this there are 332 non-mt_cache invalidations left, conditional on #35877. With #36441 merged should be about 322.