[BUG] Fix deadlocks on disconnected secondary half

[KarlK90]

Description

This fixes a deadlock bug that sneaked in with #16669. It can only be triggered on a secondary half that is not connected to the main usb connected half, thus not receiving any handshake packets. Which should be a edge-case e.g. when updating one half but still...

The problematic code that could trigger the deadlock

static THD_FUNCTION(SlaveThread, arg) {
    (void)arg;
    chRegSetThreadName("split_protocol_tx_rx");

    while (true) {
        split_shared_memory_lock(); // <-- (1.) Acquire Mutex in rx/tx thread which runs concurrent with main thread
        if (unlikely(!react_to_transaction())) {
            serial_transport_driver_clear();
        }
        split_shared_memory_unlock();
    }
}

static inline bool react_to_transaction(void) {
    uint8_t transaction_id = 0;
    if (unlikely(!serial_transport_receive_blocking(&transaction_id, sizeof(transaction_id)))) { // <-- (2.) Potentially wait forever if disconnected and no handshake packet is received.
        return false;
    }
    // SNIP
}

And now in transactions_slave() the Mutex is acquired again.

#define TRANSACTION_HANDLER_SLAVE(prefix)                     \
    do {                                                      \
        split_shared_memory_lock(); // <-- (3.) Deadlock in main thread because Mutex is already held by tx/rx thread and never released.                          \
        prefix##_handlers_slave(master_matrix, slave_matrix); \
        split_shared_memory_unlock();                         \
    } while (0)

Because manually locking and unlocking can be quite error prone, I added support for RAII-style mutex guards split_shared_memory_lock_autounlock that can be used in addition to the already existing lock / unlock functions. Unfortunately GCC cleanup attribute always wants a cleanup function with a pointer variable, so some unsexy function wrapping was necessary.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

• None ATM

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[KarlK90]

CC: @preisi