Add BSIM based BLE tests

[petejohanson]

In preparation for some major refactors of our BLE code to use State Machine Framework, this PR adds some core integration tests for our BLE code.

• Like our behavior tests, we build for a posix target, but this one using the BabbleSim board that uses BabbleSim to provide a simulated 2.4GHz PHY.
• We have a simple posix/BSIM BLE/HoG client, with a few command line flags that can alter it's behavior a bit (e.g. -halt_after_bonding or -wait_on_start=1300) so we can simulate centrals/hosts connecting to our ZMK keyboard and performing disconnects, bonding, etc.
• Like behavior tests, our ZMK posix peripheral executable uses mock KSCAN to trigger behaviors, e.g. press/release of keycodes, or switching/clearing profiles.
• The output of the central(s) is captured using pattern matching and then the filtered output is used as a snapshot to compare with the known good snapshot. That allows us to verify what clients see when interacting with ZMK, and verify that doesn't regress/change when we refactor the ZMK side BLE code.
• Add a new GHA job to run these tests.

I've layers my WIP BLE changes for SMF onto this for testing, and it properly caught a regression there, and then I have them still passing with my changes at this point.

This is a baseline set of 5 tests, but would like to supplement with more as we go.

Thoughts?

[Nicell]

Basic cleanup and a question. This is really cool! I'll need to look closer at how the main.c works, but I'm really impressed with the test run on this PR.

I noticed in the logs from the test run that the start, test logs, and pass/fail logging to GitHub actions are all jumbled up between different tests. It'd be nice if they could be grouped for better readability.

[petejohanson]

Basic cleanup and a question. This is really cool! I'll need to look closer at how the main.c works, but I'm really impressed with the test run on this PR.

I noticed in the logs from the test run that the start, test logs, and pass/fail logging to GitHub actions are all jumbled up between different tests. It'd be nice if they could be grouped for better readability.

@Nicell Ok, I did some clean up so the verbose output will only show when running a single test during development, otherwise it's quieter. See https://github.com/zmkfirmware/zmk/actions/runs/5988986557/job/16244737224?pr=1875#step:10:1 for example.

Thoughts?

[joelspadin]

It would be nice to not have the test cases and the test builds be sibling folders. If we ever need to add a "peripheral" build, then this command has to become more complicated.

[petejohanson]

Also not sure it's worth the complexity trying to generalize it at this point.

[caksoylar]

I noted some fixes for issues that shellcheck brought up, feel free to ignore any that you consider nitpicky.

[caksoylar]

LGTM for the parts I reviewed. It doesn't look like it needs any docs updates, does it?

[petejohanson]

LGTM for the parts I reviewed. It doesn't look like it needs any docs updates, does it?

It could use some docs on how to add the tests, but nothing that's end user affecting that I think is a must have for this PR.