Add DstLayout::extend

[jswrenn]

DstLayout::extend is comparable to alloc::Layout, except that it additionally handles DSTs. This is the first of two steps needed for DstLayout to support an API in the form of:

// For illustrative purposes; `align` and `packed`
// can't actually be combined like this.
#[repr(C, align(2), packed(4))]
struct ReprCStruct<T, U, V> {
    foo: Foo<T>,
    bar: Bar<U>,
    baz: Baz<V>,
}

impl<T, U, V> KnownLayout for ReprCStruct<T, U, V> {
    const LAYOUT: DstLayout = {
        use ::zerocopy::macro_utils::core_reexport::num::NonZeroUsize;
        use ::zerocopy::DstLayout;

        let min_align = NonZeroUsize::new(2); // or `None`, w/o `align`
        let max_align = NonZeroUsize::new(4); // or `None`, w/o `packed`

        DstLayout::for_type::<()>()
            .extend(<Foo<T> as KnownLayout>::LAYOUT, max_align)
            .extend(<Bar<T> as KnownLayout>::LAYOUT, max_align)
            .extend(<Baz<T> as KnownLayout>::LAYOUT, max_align)
            .pad_to_align(min_align, max_align)
    };
}

(The next step is implementing DstLayout::pad_to_align).

Despite the similarities between DstLayout::extend and Layout::extend, the former cannot be implemented in terms of the latter because Layout::extend is not const. This introduces a risk that our computations here diverge from those in Layout::extend, but this PR also includes Kani proofs that DstLayout::extend behaves comparably to Layout::extend.

Makes progress towards #29.

[joshlf]

Also assert that field._align.get() <= Self::MAX_ALIGN?

[jswrenn]

I didn't mean to assert debug_assert!(self._align.get() <= max_align.get());, and revised the PR accordingly. I don't think we need to peek into self and field and make sure they're valid — that's the job of DstLayout's constructors.

[joshlf]

We don't currently document anywhere that DstLayout's align field is guaranteed to have a particular maximum value - that's just a consequence of Rust's type rules. IMO we should either explicitly document that as an invariant and add comments at construction sites proving that it's upheld, or we should assert it here out of an abundance of caution. As this code is currently written, it could break in the future if Rust raises the maximum alignment.

[jswrenn]

I've made three changes:

1. I've verified, with Kani, that this method is robust to future increases of Rust's maximum-allowed alignment.
2. I've added debug assertions that fire if we see an alignment exceeding Rust's current maximum-allowed alignment.
3. I've replaced the + operations with explicit checked adds, and panic messages explaining what went wrong.