Fix Linux custom ioctl opcode computation

[kevinmehall]

When attempting to use the recently added custom ioctl APIs I was getting Inappropriate ioctl for device errors and found that the ioctl opcodes being passed to the kernel were equal to just the NUM part with the other components ignored. This seems to be because the shift and the mask were performed in the wrong order when combining the components.

I also added:

• a test comparing a few computed opcodes to known opcodes from linux_raw_sys as a sanity check
• documentation referring to the C macros where you would find the values to use with these functions / types.

By the way, I noticed that this library is itself using only BadOpcode with constants from linux_raw_sys rather than the ReadOpcode / WriteOpcode types. Is there any reason to prefer ReadOpcode / WriteOpcode over using an opcode found in linux_raw_sys?

The name Bad made it seem like something I shouldn't be using, but taking the value by name from linux_raw_sys seems less error prone than looking up these components in a C header file and hard-coding them.

cc @notgull

[notgull]

Whoopsie daisy

[sunfishcode]

Thanks!

[sunfishcode]

This is now released in rustix 0.38.17.