virtio: set MmioSlots drop order via code

[luigix25]

From kernel/src/virtio/mmio.rs:

    // Fields are ordered so that `mmio_range` is dropped last.
    // The MmioTransport destructor resets the device via MMIO writes, and
    // dropping `mmio_range` destroys the mapping, so `mmio_range` must be
    // dropped last.
    // This drop-order behavior is stable.
    // See https://doc.rust-lang.org/reference/destructors.html
    //
    // TODO: The destruction order should be expressed via code rather than
    // relying on field ordering. This should be addressed when moving to
    // the upstream virtio-drivers crate.

Discussion: #1110 (comment)

This depends on #1108 that will switch to the virtio-drivers upstream crate

[hiSandog]

A custom Drop implementation with the transport held in an Option would express the dependency directly: take() and drop/reset the MmioTransport first, then allow the mapping/range field to drop afterward. That is easier to review than relying on declaration order and avoids introducing ManuallyDrop unless it is truly necessary. A mock transport test can record the reset write and assert the MMIO mapping is still alive at that point.