always use __errno_location for user ABI

[yamt]

upsides:

• by avoiding direct accesses to the TLS, increase the chances for third-party libraries to provide a single binary for threaded and non-threaded wasi targets. see [1] for an example.

downsides:

• increase the overhead of errno accesses. i suppose it isn't critical as errno is typically only accessed in the error handling logic. there are a few apis like strtoul which require errno accesses even in successful cases though.

[1] https://github.com/bytecodealliance/wasm-micro-runtime/blob/d95b0e3d46da8e88f484f236cb4222f5a6dc5926/core/iwasm/libraries/lib-socket/src/wasi/wasi_socket_ext.c#L15-L33

[rvandermeulen]

We hit an issue that I believe may be related to this bug while working to update Firefox's WASI sysroot from wasi-sdk-20 to wasi-sdk-30. When linking a non-threaded wasm32-wasi binary (SpiderMonkey compiled to WASM), we get:

wasm-ld: error: relocation R_WASM_MEMORY_ADDR_TLS_SLEB cannot be used against non-TLS symbol `errno`
wasm-ld: error: ... in non-TLS section: .bss

The mismatch is that __errno.h declares extern _Thread_local int errno, causing the compiler to emit TLS relocations, but the compiled errno symbol in wasi-libc.a lands in .bss (non-TLS) since thread_local is a no-op without shared memory. We're working around it locally by stripping _Thread_local from the declaration and thread_local from the definition for the wasm32-wasi target, but a proper upstream fix would be welcome.