fix: definite assignment for composite types

[DavePearce]

Summary

Currently, the definite assignment algorithm does not work well for composite types. Specifically, it does not catch cases where a type is partially initialised.

Example

A simple example would be this:

fn f() -> (r:[u8;4]) {
   r[0] = 1
}

The problem here is that e.g. r[1] is not initialised. Whilst this example illustrates array types, it applies to any composite type (e.g. structs).

Approach

There are a few obvious approaches:

• (Full Initialisation) A common approach to this problem is to require that arrays are always initialised in full. This would require an array initialiser expression form, but simplifies the definite assignment algorithm.
• (Partial Initialisation) We could upgrade the definite assignment checker to support partial initialisation somehow. That way, it can track exactly which "pieces" of a composite type have been initialised and which have now.
• (Delay Definite Assignment) Another approach would be to delay definite assignment until after flattening has been performed as, this way, all the distinct components of a type are made explicit as variables. A challenge here would be reporting a sensible error to the user about which part of the original variable was not initialised.