Use bitbybit to encode the MeshPipelineKey

[nicopap]

Objective

MeshPipelineKey is a "packed struct". Using bitflags! doesn't scale for a packed struct, as the key grows in size, so does the complexity of setting its fields and reading them.

Solution

There are a few crates on crates.io defining macros to make handling packed struct much easier:

• packed_struct: A venerable crate used in many different libraries, allow reading structs from packed &[u8] and vis-versa
• bondrewd: An old crate generating "reader" and "writers" so that specific fields can be read individually, avoiding the cost of unpacking other fields
• bitbybit: A relatively recent crate with not many users, based on arbitrary-int, of the same author.

Why chose bitbybit?

• It supports arbitrary backing storage for our packed structs (unlike packed_struct and bondrewd that takes a &[u8]), which is important for performance
• It supports reading subset of fields, similarly to bondrewd. The struct generated by the macro is pretty much a MeshPipelineKey(u32), then each method does the bitshifting/masking necessary
• It is post 1.0, and still maintained.

Downsides of bitbybit:

• There are some cryptic errors hidden in there if you are not careful about how you convert from an arbitrary-int to a rust native type (eg: u3 -> u8)

Other crates simply do not fit the bill, so I took the one that enabled me to do what I want.

We then replace the bitflags! definition for MeshPipelineKey by one based on bitflags. I'm pretty happy with the result. -160 and only for MeshPipelineKey is promising.

Future work

1. This still doesn't fix my major gripe with the rendering code, which is the decoupling between key, shader defs and conditions for shader defs. (But reducing the amount of code reduces how much thinking one has to do to inspect code)
2. There are other pipeline keys that could do with this improvements, but I'm refusing to update them before this PR gets merged. It's going to hit a lot of merge conflicts and I don't have the time to resolve all of them. I also need the greenlight from the community before moving forward with more changes.

---

Migration Guide

The MeshPipelineKey associated consts used to compute specific fields have been removed, please replace their usage by accessors such as MeshPipelineKey::with_taa and MeshPipelineKey.may_discard. With this change, code using MeshPipelineKey is likely to be cleaner and easier to read.

[nicopap]

I need to think a bit more how to handle MSAA flags. It's very strange that the Msaa enum is only up to 8 samples, while the docs advertises "up to 128"

[lain-dono]

@nicopap Nvidia GTX 1080 supports x16 and x32 msaa samples. Just to give you an example.

WebGPU and wgpu.rs doesn't explicitly limit you.

You need 2 bits to support x1, x2, x4 and x8. Another bit gives you x16, x32, x64, x128. see #5826 (comment)