Handle concurrent initialization of modules

[WojciechMazur]

The current implementation of the module accessors (Scala's object defining at least 1 field) is not aware of multithreading. It can end up in multiple initializations of module, or returning not fully initialized object.

This change adds a synchronized version of module accessors using the non-locking mechanism for the synchronization of threads. It comes with a higher overhead than the legacy version, so compilation with disabled multithreading would use the old mechanism.

A new technique due to higher complexity is implemented in C instead of plain NIR structures.
*An uninitialized module is null as null in the modules array.
( Upon the first load of the module, we can observe null and make a compare and swap operation setting the module value to the Initialization state which is a pointer to the structure containing intermediate data (eg. address of allocated object).

• If this CAS operation succeeded to start to allocate instances in GC, store information about an instance in context, and invoke the module constructor
• Otherwise if CAS fails, we get to the waiting state, where we poll for the end of initialization and possibly poll GC safepoint / yield execution to another thread.
• If the module constructor or some of the methods it calls needs an instance of the module, we would return to it a partially initialized instance from the context. (should be safe in most the cases, since the Scala compiler would not allow us to refer to not yet initialized fields)
• Finally fully initialized object is assigned to the modules slot finishing the process of initialization.