Support packed structs in std.io.Reader and std.io.Writer

[kj4tmp]

intended to close #12960

successor to #21562

Summary
This PR adds support for packed structs in std.io.Reader and std.io.Writer.

Some rationale:

1. I chose to not read/write padding bytes of packed structs because I think that most users are using packed structs to avoid padding, and thus the padding due to alignment would be annoying.
2. I chose to restrict packed struct parameters to having a @bitSizeOf that is a multiple of eight because the user is using the reader / writer on a byte stream, and should be expected to add padding fields to the packed struct if they wish to have padding to align to bytes.
3. For endianness conversion, I chose to use std.mem.reverse instead of byteswap on the backing integer because I think it declares my intent more precisely: to reverse the bytes that underly the packed struct. It declares explicitly that I am relying on the big endian representation being the bytes reversal of the little endian representation. Note that this implementation may need to be changed if packed struct can later contain arrays. Packed structs can't contain arrays #12547

Questions
1. Should I be using @compileError as I am in the switches? Or perhaps unreachable?

Test Plan
The unit tests added with this PR should pass.

Feedback welcome, as always!

[kj4tmp]

There seems to be precedent for using @compileError like I am. For example:

zig/lib/std/bit_set.zig

Line 322 in d23db94

if (mask_info != .int) @compileError("ArrayBitSet can only operate on integer masks, but was passed " ++ @typeName(MaskIntType));

[rootbeer]

Code and comments look nice to me. I'm not convinced the packed struct endianness is handled correctly, but I might be looking at it incorrectly.

[rootbeer]

PR looks good to me. The updated tests look excellent.

I'm still confused about the handling of big-endian packing, but I'm fine to accept its just my expectations that are wrong, not the code.

[kj4tmp]

@rohlem @rootbeer I'm not sure whether I should be clinking "resolve conversation". I would generally expect the conversation creator to click resolve when they feel it is resolved? Might be worth a mention in the contributing guidelines.

[rootbeer]

@rohlem @rootbeer I'm not sure whether I should be clinking "resolve conversation". I would generally expect the conversation creator to click resolve when they feel it is resolved? Might be worth a mention in the contributing guidelines.

Yeah, I'd resolve them if I could... According to GitHub docs only PR authors or folks with write access to the repo can resolve a conversation. So in this specific case, all my comments are addressed. Sorry for the extra hassle.

[kj4tmp]

given that packed struct equality operator just got merged #21679
I will convert my tests to use testing.expectEqual instead of testing.expectEqualDeep, either as soon as I can finish building from source or get my hands on today's nightly.