I also included changes to the rest of the SIL optimizer pipeline to ensure that
the part of the optimizer pipeline before we lower tuple_addr_constructor (which
is right after we run TransferNonSendable) work as before.
The reason why I am doing this is that this ensures that diagnostic passes can
tell the difference in between:
```
x = (a, b, c)
```
and
```
x.0 = a
x.1 = b
x.2 = c
```
This is important for things like TransferNonSendable where assigning over the
entire tuple element is treated differently from if one were to initialize it in
pieces using projections.
rdar://117880194
DI had trouble with this pattern:
%s = struct_element_addr ...
%t0 = tuple_element_addr %s, 0
%t1 = tuple_element_addr %s, 1
%f = function_ref ...
apply %f(%t0, %t1)
This is because the NonLoadUses map only stored a single use of a
tuple element per instruction, preventing instructions such as
'apply' from being able to use multiple tuple elements.
In other cases where this comes up, such as with 'assign' and
'copy_addr', DI scalarizes the tuple operation by projecting
each component, however clearly this can't be easily done with
an 'apply'.
Instead, we can get DI out of the business of scalarization, at
least for instructions which are known to perform an unconditional
initialization.
We do this by changing the NonLoadUses map to store a vector of
DIMemoryUse IDs instead of a single value.
