If the user has a derived `struct` type:

```hlsl
struct Base { int b = 1; }
struct Derived : Base { int d = 2; }
```

Then it is still reasonable for them to want to use initializer lists when declaring variables using the `Derived` type:

```hlsl
Derived x = {};
Derived y = { 7, 8 };
```

This change implements two missing pieces of functionality in the Slang compiler to allow this case:

* First, when the front-end semantic checks are applied to an initializer list, if the type being initialized is a derived `struct` type it always expects to find initialization arguments for its base type before those for its fields.

* Second, when lowering an initializer-list expression from the AST to the IR, the compiler expects the first argument in the list to be the initial value for the base field (if any). This also applies to default-initialization of fields/variables.

This change slightly entangles front-end logic with the logic for how struct inheritance is lowered to the IR, but the behavior is unlikely to confuse users who expect C++-like layout.

It is worth noting that with this change it should be possible to initialize the base type using either a nested initializer list or flat arguments:

```hlsl
struct BigBase { int x; int y; int z; }
struct BigDerived : BigBase { int w; }

BigDerived a = { {1,2,3}, 4 };
BigDerived b = { 1, 2, 3, 4 };
```

This behavior should Just Work because of the existing C-like rules for initializer lists where an aggregate can be initialized by either a `{}`-enclosed block or distinct values for its leaf fields.