fix(evm_arithmetization): Adjust layout of CpuGeneralColumnsView

[gio256]

Addresses #340.

I'm very open to suggestions if there is a way to make this less cumbersome.

It could be nice to add some miri tests for this and other conversions, but I can't think of a clean way to run them in the CI. Miri doesn't support inline assembly, so we would need a way to avoid running any test that touches assembly in plonky2. Adding cfg attributes to every other test seems prohibitive. Maybe a naming scheme for miri tests and a cargo test filter would be good enough?

[Nashtare]

LGTM, minus a tiny nit and a potential request (upon feasibility).

[Nashtare]

Ideally, we'd also have some const_assert on all these above that ensures that the "unpadded" length of these variants (apart from LogicView) is actually smaller than the _unused field of Cpu (to ensure coexistence viability). But I'm not sure this is possible with current Rust.

[gio256]

I can't immediately see a way to make an assertion about the unpadded size of a field without generic_const_exprs. Maybe that's an argument for not padding in the first place?

With the padding, the two options I see are:

• The small refactor mentioned above (splitting into two unions of different sizes).
• Adding some manual assertions more-or-less as "documentation". e.g.

/// View of the first three `CpuGeneralColumns` containing exception code bits.
#[repr(C)]
#[derive(Copy, Clone)]
pub(crate) struct CpuExceptionView<T: Copy> {
    /// Exception code as little-endian bits.
    pub(crate) exc_code_bits: [T; 3],
    /// Reserve the unused columns.
    _padding_columns: [T; NUM_UNION_COLUMNS - 3],
}
const_assert!(3 <= NUM_COLUMNS_SHARED_WITH_STACK);

[Nashtare]

Otherwise we can have it as unit test, so that we can instantiate it concretely and then do the bound checks on the fields themselves. But non-blocking