Add multi-threaded SB performance tests

[jphickey]

Is your feature request related to a problem? Please describe.
The SB performance tests that were added in #2380 are single threaded. Thus, there is never any contention/blocking on the shared data structures (i.e. the SB shared data mutex is always available), and when receiving there is always a message in the pipe.

This is adequate to gauge the computation done strictly within the SB activity, but does not gauge how well it scales to real mission use, where there is typically a different app doing the sending vs. receiving.

Describe the solution you'd like
Add additional test cases that use multiple threads.

Case 1: Two threads, Thread 1 doing a CMD send and CMD receive, and Thread 2 doing a TLM send and TLM receive.

This will mean both threads are competing to access the SB shared data structures and thus depends on the mutex working properly, and performance will degrade if there is too much work being serialized by the mutex. However, it is still not entirely flight-like because the same thread is still doing send + receive. But, it avoids synchronization/throttling issues and there is no chance of msglim overrun.

Case 2: Four threads Thread 1 doing CMD send, thread 2 doing TLM send, thread 3 doing CMD recv, and thread 4 doing TLM recv.

This is the most realistic in that it matches how CFS apps typically work. However, it also makes it difficult to run at full speed because of the lack of synchronization in SB. Therefore, this needs to be externally synced, which will reduce performance.

Additional context
With recently expressed concerns about SB performance, we need better benchmarks.

Requester Info
Joseph Hickey, Vantage Systems, Inc.