Refactor thread local storage

[Apprentice-Alchemist]

This implementation supports a maximum of 4,294,967,295 tls slots across the lifetime of the process (before the counter overflows). That should be enough, right?

Closes #891

[ncannasse]

Interesting but I don't think i want to add a map access for every TLS, as we want them to be extra fast, so as much native as possible. We should return null in hl_tls_alloc when we can't alloc and throw an exception on the Haxe side. It's then up to the user to limit his TLS usage and eventually use a Map instead of allocating too many.

[Simn]

Could we at least run the GC when we can't allocate? I think my original problem was a variant of this:

function main() {
	final tooMany = 513;
	for (_ in 0...tooMany) {
		new sys.thread.Tls();
	}
}

So all these TLS could be freed, but if the GC never runs they aren't.

[ncannasse]

I guess we could try once before returning null indeed.

[Apprentice-Alchemist]

Interesting but I don't think i want to add a map access for every TLS, as we want them to be extra fast, so as much native as possible. We should return null in hl_tls_alloc when we can't alloc and throw an exception on the Haxe side. It's then up to the user to limit his TLS usage and eventually use a Map instead of allocating too many.

HL is the only target (apart from Neko) that uses pthread slots directly, so I don't think this argument makes much sense.
In this case I think consistency between targets is more important than performance.

This approach also solves the GC leak issue mentioned in HaxeFoundation/haxe#12388

[Apprentice-Alchemist]

Switched to a new implementation that should be nearly as fast as native implementations.

[tobil4sk]

This is an abi breakage, maybe it's better to deprecate it and keep a dummy implementation