This fixes the handling of mov.w/mov.t relocations (IMAGE_REL_ARM_MOV32T) that
cannot be split up. This occurs in a very specific case of two chained IT
blocks with the load of an address being placed in the third slot (position 4).
Because IT blocks may contain 1-4 instructions, and the load is a pair of
consecutive instructions, placement into slot 3 causes a spill into the second
IT block.
The resulting instruction block appears in the following form:
itttt {type} {dont care} {dont care} {dont care} mov.w {address} it[ttt] {type} mov.t {address} {dont care} {dont care} {dont care}
In particular, the problem is that the mov.w/mov.t relocation of the address is
split with a secondary instruction in between them. This is problematic on
Windows, where the IMAGE_REL_ARM_MOV32T relocation cannot be split as the loader
expects that the instructions occur sequentially.
Unfortunately, constructing a test case for this scenario is quite tricky and
extremely fragile, and until a flexible system for running optimisations over
MachineFunctions is implemented, this seems too flaky to construct a test case
for.