Improved support for changing symlink permissions

Hello 👋,

I'm trying to implement some logic that extracts a zip file using `cap-primitives` and ran into a snag with how `fs::set_permissions` is currently implemented. In the [general UNIX implementation](https://github.com/bytecodealliance/cap-std/blob/58df14be1b80ade7464f754fa1aa06da2f5fe26d/cap-primitives/src/rustix/linux/fs/procfs.rs#LL28C41-L28C60) it says even `AT_NOFOLLOW_SYMLINK` with `fchmodat` is not enough because it would modify the symlink itself, and that it is undesirable behavior. So, because of that, its implemented as a regular `fchmod`. Its not clear to me why this is undesirable at a glance though.

In my case however, I am actually trying to change the symlink itself based on permission bits that come from the zip file and the current behavior makes that impossible as it always dereferences the symlink and changes the permissions of the linked item instead. This is an odd use case, but I have the constraint of the process `umask` set at startup being more restrictive then what the zipped file permissions are, so I need to change everything written out to disk after writing to get the correct resulting permissions.

Is this a feature that you would consider adding to `cap-primitives`, or is "weird" symlink handling something that's considered out-of-scope?

Start with cap-primitives/src/rustix/linux/fs/procfs.rs and trace the fs::set_permissions implementation, especially the AT_NOFOLLOW_SYMLINK and fchmod behavior described in the issue. Investigate the stated safety rationale and the Unix platforms involved, then determine whether changing symlink permissions can be supported without altering the current default semantics. Done means a decided API and scope, with behavior for the zip-extraction use case clarified.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.