Avoid per-instance lock object in InterruptibleLazy and DelayInitArrayMap

[auduchinok]

I've been measuring memory allocations on some my changes and found out that these sync objects retail a lot of memory due to usages like in ImportILTypeDef. This is a debatable change: it makes things more dangerous (an issue could be if someone locks on the lazy itself) but at the same it's an implementation detail inside the compiler which is fairly advanced, so I hope that it can be used responsibly.

[majocha]

The way System.Lazy does it is they clear the sync object field via null assignment as soon as the value is created, but it is a bit complicated.

[auduchinok]

The way System.Lazy does it is they clear the sync object field via null assignment as soon as the value is created, but it is a bit complicated.

Thanks for the suggestion! The problem is it still keeps the memory for that field, and for many thousands of types it's becoming a bit too much.

[auduchinok]

Here's an interesting discovery about how this PR overlaps with #20090:

syncObj is worth much less than its own branch measured, and that's expected. It gave −80.3 MB on FSharp.Common when addConstraintSources was importing all 107 K types (≈1 M InterruptibleLazy+syncObj pairs); with only ~35 K types imported there are proportionally fewer lock objects left, and the branch's own DelayInitValue already locks on this. Hence −14.3 MB here. The two wins overlap; they don't add.