Lifted struct accesses should account for struct alignment

I recently encountered a case where I have a structure that looked something like:

struct my_struct_type
{
    uint32_t foo;
    uint32_t bar;
    uint8_t data[64]
};

where the data field was accessed with:

orr    x21, x9, #0x8 {my_struct}

which when lifted to MLIL looked like:

int64_t* x21_1 = &my_struct | 8

rather than the expected

&my_struct.data[0]

In the ABI, this orr is valid (rather than using an add) because this structure was allocated on the stack and thus guaranteed to be aligned to 16 bytes. To express this idea to binja, I tried making my struct use a 16 byte alignment:

>>> struct_var = bv.types['my_struct_type'].structure.mutable_copy()
>>> struct_var.alignment = 16
>>> bv.define_user_type('my_struct_type2', Type.structure_type(struct_var))

Unfortunately this did not assist the lifter figure out what was going on and I ended up having to just patch the instruction into an add (which worked). It would be useful if the structure alignment information could be taken into account somehow here to figure this out.

Also, it would be very much appreciated if there was an easier way to declare structure alignment, perhaps by allowing me to write the following?:

struct my_struct_type __attribute__((aligned(16)))
{
    uint32_t foo;
    uint32_t bar;
    uint8_t data[64]
};

Reproduce the example with the MLIL lifter, the aligned my_struct_type, and the bv.types, mutable_copy, define_user_type, and Type.structure_type APIs. Inspect how the ORR access and structure alignment metadata are interpreted. Done means the lifted access resolves to my_struct.data[0], with a documented or supported way to declare 16-byte structure alignment.