Thread / EventLoop may fail due to undefined init order

I've heard that the order of ``__init__`` should be seen as target-dependant and thus undefined. The new threading logic seemingly assumes a certain init order to function.

- https://github.com/HaxeFoundation/haxe/blob/development/std/sys/thread/Thread.hx#L307
``mainThread`` is initialised within the init function, this does:
```hx
mainThread = new Thread(ThreadImpl.current());
```

- https://github.com/HaxeFoundation/haxe/blob/development/std/haxe/EventLoop.hx
EventLoop also uses an init function, one thing it does is:
```hx
main.thread = sys.thread.Thread.main();
```

The function ``Thread#main`` is defined as:
```hx
public static inline function main() {
return mainThread;
}
```

The returned ``mainThread`` is the same one initialised in Thread's init function, yet EventLoop's init function also tries to access it. This means this code only works if Thread's init function is ran before EventLoop's init function. Otherwise ``mainThread`` (and by extension ``Thread#main``) would be ``null``

I see 1 of 2 possibilities:
- The order of ``__init__`` functions is defined.
- This code is "faulty" in the sense that it may not be guaranteed to work on all targets.

A few other people and me are currently working on a new target and this did indeed break on our target. Is this our user-error or an issue with how it's implemented in the stdlib?

Thanks in advance,
mikaib

Start with std/sys/thread/Thread.hx around the __init__ function and Thread.main(), then read std/haxe/EventLoop.hx where main.thread is assigned. Reproduce the initialization sequence on the affected target and compare it with a working target; done means the standard library no longer depends on an unsupported __init__ order or the order is explicitly guaranteed.

Written by the indexing model from the issue text.