Native uses of alloc_array are duplicated in the native test files.
Those will be removed when the tests are ported to Rust.

This also changes how we store the next free index a little bit. The
constant `FULL` is gone, when the next free location is equal to the
array length that's how we know the table is full now. Also, `FREE_SLOT`
no longer next free location shifted left, it holds the next free
location directly (not shifted).

- Introduced `as_blah` methods to convert a SkewedPtr or *Obj to other
  object types. These methods check the type in debug mode.

- Improve error reporting, we know show details in assertion failures

- Temporarily link with debug runtime to enable sanity checking by
  default for now

Also refactors object_size slightly

Fixes #2216

After several hours of debugging I found out that this struct

    #[repr(C)]
    pub struct Bits64 {
        pub header: Obj,
        pub bits: u64,
    }

is compiled with one word padding between the fields when compiled to
wasm32 targets, but *not* when compiled to i386!

(This is weird, but I think not a bug, as wasm32 doesn't have a standard
ABI, it's just "whatever LLVM implements", and apparently LLVM decides
to align fields when compiling to wasm32)

As a result `size_of::<Bits64>` returned 4 words, not 3, which is
inconsistent with the compiler's view of this type.

This doesn't really break the garbage collector. This is because we
don't care about the bit contents of this type in the GC, and it's fine
to copy 4 bytes instead of 3 bytes for this object as long as the
generated code will find the bit contents in the right place.

In other words, if we generate this in the compiler

    | TAG_BITS64 | word1 | word2 |

and the GC copies it as

    | TAG_BITS64 | word1 | word2 | <one word garbage> |

to tospace, that's still fine for the generated code, as it can still
find the contents in the right places.

However it's a problem for `dump_heap` as it linearly scans the heap. If
we generate the first layout above then call `dump_heap`, it skips over
the next object's tag, thinking that `Bits64` is 4 words.

Even if it was OK the RTS and compiler should be in sync about the
object layouts.

I now replaced all `repr(C)` with more precise `repr(transparent)` and
`repr(packed)`. Relevant documentation:
https://doc.rust-lang.org/nomicon/other-reprs.html

I think this is a good idea even for the cases where repr(C) did not
cause any problems, because repr(C) raises the question of "how would
this be represented in C?". transparent and packed are much more
precise:

- packed: Don't align fields, don't add padding
- transparent: Represent as if the struct (newtype) did not exist
  (newtypes are represented this way on most platforms anyway, see the
  linked documentation above)

…ctions

this is easier to build on all platforms, compared to building for 32bits.

It also means we are testing things closer to what we really run.

Run the RTS tests in wasmtime/WASI