Tar: add executable_bit_only support.

[Rexicon226]

Closes: #17462

Still working on polishing this and seeing if there any any issues with this. To be honest, I'm just doubting that it's this simple, so I need some time to make sure.

Trying it on something like ci folder, it seems to be working.

if I'm missing something super obvious please let me know.

[Rexicon226]

Would it make sense to change the properties of the file, after it has been confirmed to successfully been written?

[ianprime0509]

From what I understand, the more difficult part of #17462 is implementing the necessary support for Windows using ACLs (the last part of the referenced TODO comment). I'm not familiar with Windows development, so I'm not sure specifically what ACL is being referred to or how to interact with it using Windows APIs, however.

While completely ignoring the executable bit on Windows is simpler to implement, it would cause problems when #17463 is implemented, because it would cause package hashes to differ on Windows vs other platforms: the executable bit would be considered in the hash on POSIX platforms but unavailable on Windows. (This will also be an issue on WASI, but it looks like WASI preview 2 is intended to support file modes similar to POSIX at some point: https://github.com/WebAssembly/wasi-filesystem/blob/d86efbe6c8b7590cfc1306c7bb02dbf960041434/wit/types.wit#L145-L157)

[Rexicon226]

So, Windows ACL, from what I understand, is quite a lot different from other ACL implementations. ACL standing for "Access-control List". It's just a general term for a file permissions "format" I guess you could call it.

Here is good article I found for analyzing the Windows ACL using the win32api here. And this one for creating and modifying them here. I've never delved deep into the Windows file system methods, but they seem quite interesting and doable. I'm going to spend a couple days exploring implementations for ACL control on windows. Current std simply forces things like "chmod()" to just accept u0, and are useless.

[andrewrk]

std.fs.File.chmod should be deleted, since std.os (to be renamed to std.posix in #5019) has the API and it is a POSIX-only API. And then std.fs.File can be augmented with cross-platform API, if possible.

Either way, std.os.windows can will have the Windows-specific API, and the cross-platform abstraction will either go into std.tar or into std.fs.File.

[Rexicon226]

Makes sense. I will make a draft pr to track when I have something. Once the reformat of std.fs.File is done, I'll come back to this PR and re-implement it with the "new" api.

[andrewrk]

Needs a test, needs a rebase on the updated tar implementation. If you want to continue this work please open a new PR.