Replace linux_rustix opt-in backend with linux_raw

[newpavlov]

This PR replaces the linux_rustix opt-in backend introduced in #520 with linux_raw opt-in backend based raw syscalls implemented using asm!. It noticeably reduces dependency footprint of the crate (see concerns raised in #433). Unfortunately, it means that we have to implement the raw syscalls ourselves.

This PR implements linux_raw support only for target arches with stable asm!. Nightly-only support for other targets can be added in later PRs.

[josephlr]

Personally, I think this seems like a lot of added complexity for a backend that is not enabled by default. I think that we should try to find some other way to solve the issues raised in #433, or just not have a rustix/raw-syscall backend right now.

Getting raw syscalls correct can be very complex if we want to support a range of targets, and I don't think we are well situated to maintain such things.

[newpavlov]

just not have a rustix/raw-syscall backend right now

Yes, it's a reasonable option. We can delay this backend until a later release.

But I believe we should eventually have a "raw Linux syscall" backend as it was requested several times (#401, #424).

Getting raw syscalls correct can be very complex if we want to support a range of targets, and I don't think we are well situated to maintain such things.

I do not agree with the "very complex" assessment. As mentioned in the comments, I've mostly copied the battle-tested code from rustix, intentionally limited the set of supported targets and did not include any vDSO complexity.

Ideally, I would prefer to have the syscall stuff in a separate lean crate, but, unfortunately, rustix/linux-raw-sys developers weren't open to such changes. I could create my own fork of linux-raw-sys, but would it be really better than the current solution?