feat: Add fs::ioctl_ficlonerange for FICLONERANGE

[pauldoo]

Alongside fs::ioctl_ficlone for FICLONE, add support for the FICLONERANGE operation.

I have tested this on a local btrfs filesystem and I believe XFS with reflinks should support this too.

The existing ioctl_ficlone claimed that SPARC is not supported. I don't have a SPARC system to test on, but I'm assuming that if whole file cloning (reflinking) isn't supported on SPARC, then neither too would range cloning.

[pauldoo]

I believe the test failures are unrelated to my changes. They are being tracked here: #1607

[pauldoo]

It seems to be rustix convention that all these functions are marked #[inline]. So I have used it too on this ioctl_ficlonerange function.

But it's it's not clear to me why this is done....

I doubt it's for performance reasons. All of these functions are wrappers to system calls, and the cost of any system call will dwarf the saving from inlining. I'd like to hear the opinion of rustix maintainers on this.

[pauldoo]

I realise now that not all of the test failures are unrelated to my change. I'll follow up in a few days with a new revision.

[pauldoo]

I have fixed the "no default features" failure from my first attempt and I think the code is good now. I confirm the code is working correctly when I ensure the test is using btrfs which supports this ioctl (TMPDIR=/path/to/btrfs cargo test --features stdio,fs ioctl).

I'm not sure what the other CI failures are about but I don't think they are caused by this PR.

[pauldoo]

@sunfishcode Sorry for the direct ping. Can you confirm for me if there is anything else I need to do on my end for this PR to be mergeable? I think the failed checks on this PR are not related to my commit, but instead due to the libc MSRV issue that I believe you are aware of.

[oech3]

Is there any way to restrict copy_file_range to reflink copy?
FICLONERANGE is difficult to use due to alignment requirement and essentially subset of copy_file_range.