Fix INT1_IO_CTRL and INT2_IO_CTRL config when using SPI 4 wire: do not use burst writes

[SzabolcsGergely]

There is a BUG when using SPI 4 lines, enabling interrupt output pins doesn't work. The issue is doing a 3 byte burst write. This is likely a HW issue on the IMU side. (?)

Here you can see captures from a logic analyzer. Can be viewed using this tool.
D5 (INT1_IOCTRL_RW_ENABLE (debug)) is active when doing operations with INT1_IO_CTRL == 0x53 register.
The relevant trace is for bmi2_set_int_pin_config function:

1. First we read 3 bytes from 0x53 (INT1_IO_CTRL) (to do read-modify-write): 0x00 0x00 0x00
2. We set the config values, and write 3 bytes to 0x53: 0x80 0x00 0x00
3. Reading back the values from 0x53 results in zeroes: 0x00 0x00 0x00

Note that setting the interrupt latch mode seems to be working, so the issue is limited to registers 0x53 (INT1_IO_CTRL) and 0x54 (INT2_IO_CTRL)

SPI write HAL implementation:

BMI2_INTF_RETURN_TYPE bmi2_spi_write(uint8_t reg_addr, const uint8_t *reg_data, uint32_t len, void *intf_ptr)
{
    uint8_t dev_addr = *(uint8_t*)intf_ptr;

    HAL_GPIO_SET(dev_addr, 0);
    HAL_SPI_Transmit(&reg_addr, 1);
    HAL_SPI_Transmit((uint8_t *)reg_data, len);
    HAL_GPIO_SET(dev_addr, 1);

    return BMI2_OK;
}

Which respects datasheet section 6.4:

Multiple write operations are possible by keeping CSB low and continuing the data transfer. Only the first register’s
address has to be placed in SDX. Addresses are automatically incremented after each write access as long as CSB
stays active low. The principle of multiple write is shown in figure below:

Other details: SPI speed was set to 1 MHz, CPOL/CPHASE 1/1. Changing these settings didn't affect the outcome.