BUG: free-threaded dynamic loop addition and ideally loop replacements in ufuncs

I didn't think this would get back so quickly, but we should allow dynamic addition of loops in ufuncs.
Previously, this was OK at least when done during promotion (which is to me the interesting part -- other times could add their own lock, but this path cannot).

Now, we could just disable the duplicate addition check and things will probably work, but not sure what is best.
I am not sure there is much of a point to not just lock everything when we do promotion (promotion should be very rare!).

I also would like to allow loop replacement eventually, and this has come around a bit quicker now as well.
Now, that requires clearing the cache, which is already similar to what is happening when growing, but the trivial way to add it requires leaking the cache buckets (which growing also currently does?!).

We can just move back the locking one level up, but I do wonder a bit if all of this is actually worth it compared to an RWlock?

Right now, I added dynamic loops for imag/real, but it is internal, so there is the "ignore that it is already added" flag public already.

CC @kumaraditya303 and @ngoldbaum.

No file or test is named. Start by locating the ufunc promotion, dynamic-loop, cache-growth, and locking paths, then trace how free-threaded duplicate loop addition is handled. Done should mean dynamic loop addition is safe during promotion, with a clear approach for cache clearing and eventual loop replacement.