std: implement basic io and improve alloc in uefi

[RossComputerGuy]

Largely based on #19486, this PR marks me starting to work on UEFI support in Zig again. This time, there will be multiple PR's instead of one so it becomes easier to manage. This PR simply makes the zig init example build.

I tested this in QEMU by loading in OVMF, entering the UEFI shell, loading FS0:\bin\$.efi. The zig-out can be shared by adding: -drive file=fat:rw:zig-out.

[alexrp]

Last I talked with Andrew about the future of std.posix, one thing we agreed on is that probably all Windows code in std.posix should be deleted. I would expect that the exact same thing is true of UEFI, as it is also not a POSIX platform in any meaningful sense?

[RossComputerGuy]

Yeah, I agree. The UEFI POSIX stuff is just a POSIX wrapper around the UEFI protocols. We can always ditch it. UEFI is close to Windows so I think whatever we do for Windows and POSIX, it would apply to UEFI.

[alexrp]

Should UEFI be treated as a proper single-threaded target?

zig/src/target.zig

Lines 66 to 81 in 82f35c5

	pub fn alwaysSingleThreaded(target: std.Target) bool {
	_ = target;
	return false;
	}
	pub fn defaultSingleThreaded(target: std.Target) bool {
	switch (target.cpu.arch) {
	.wasm32, .wasm64 => return true,
	else => {},
	}
	switch (target.os.tag) {
	.haiku => return true,
	else => {},
	}
	return false;
	}

[RossComputerGuy]

Yes, I just didn't know where the source was which defined that heh.

[RossComputerGuy]

I've updated this and changed the defaultSingleThreaded for UEFI.

[mochalins]

Out of curiosity, is UEFI not always single threaded instead of just default single threaded?

[RossComputerGuy]

You technically could implement a form of multithreading, just like with wasm. It's just builtin.single_threaded will default to true when single_threaded is not changed in your build. You probably could write a custom scheduler + mutltithreading stuff and use root.os stuff to get it working but no implementation will be made for upstream.