Implement %makearray_dynamic{,_uninit}

[mshinwell]

This implements two primitives (exact signature of the second yet to be decided):

external[@layout_poly] makearray_dynamic : ('a : any). len:int -> init:('a [@local_opt]) -> ('a array [@local_opt]) =
  "%makearray_dynamic"

external[@layout_poly] makearray_dynamic_uninit : ('a : <TBD>). int -> ('a array [@local_opt]) =
  "%makearray_dynamic_uninit"

These provide array creation at runtime either on the heap or the local stack. All layouts, including those involving unboxed products, are supported. The arrays may be either initialized or uninitialized. Any excess 32-bit word at the end of an initialized array (for arrays of float32# and int32#) is deterministically initialized to zero.

Uninitialized arrays may only be created if the layout completely prohibits valid OCaml values (which includes things of type int and equivalent, even if they occur in a context such as #(int * int32#) where the resulting block will be non-scannable). This ensures soundness in the case where such array is inadvertently read before being initialized. (Consider for example the case where the uninitialized data fails to have the bottom bit set.)

Arrays whose array kinds involve GC-ignorable unboxed products are always allocated as mixed blocks, even in cases such as #(int32# * int32#), and 32-bit elements are never packed therein. This means that the representation currently differs from e.g. int32# array, which uses a custom block, with packing. As has been discussed, we intend to move everything to mixed blocks in the future, and there will no doubt be improvements to packing for unboxed products.

We should discuss whether it is undesirable for the representation of all-int arrays (which will end up as mixed blocks in this PR) to be different from e.g. that obtained from array literals, for the purposes of the polymorphic operations.

(This PR currently includes a test commit from ccasin@a55f456)

[mshinwell]

One thing we need to check: preservation of evaluation order (and non-duplication) during the Lambda-to-Lambda transformations here.

[TheNumbat]

Minor comments. I think it's fine that all-int unboxed tuple arrays end up with the mixed block representation, though it is a bit strange that this applies to singleton tuples too.

[TheNumbat]

(Also as Chris noted, the tests are currently only running in bytecode)

[mshinwell]

Note that the runtime4 CI tests are not yet expected to pass, I'll port the runtime5 changes to runtime4 once review has been completed.

[TheNumbat]

Approving modulo discussion with Chris

[ccasin]

Looked at the bits I was tagged for - some minor suggestions.

[mshinwell]

I've also rebased this.

[mshinwell]

Have rebased.