Rp2040 multithreaded target support

[sberkun]

This PR adds multithreaded support from the RP2040 platform. Builds off of the work in #291.

Corresponding PR in lingua-franca: lf-lang/lingua-franca#2178.

Some important notes on this implementation (main differences from Abhi's implementation):

• semaphores are used as an analog for condition variables. This works because the condition variable only needs to notify at most one other thread. Will trigger a spurious wakeup later if the other thread is not waiting on the condition variable.
• only one other thread (in addition to the main thread) is allowed. This will be a tricky constraint for the runtime to work with (in particular, scheduling enclaves and watchdog timers will need some work), but will allow for the runtime to work with no context switches.

Edit: this PR is meant as part 1 of a series. This PR is meant to be minimal changes to get the threaded runtime working. The next few PRs will be:

• modify the runtime so that the main thread also runs a worker
• merge atomics implementation with Zephyr
• lf_initialize_clock return value

[gundralaa]

Pretty cool someone’s picking this up :) The only major comment I have is enabling more than 1 worker thread. With only one, it defeats the purpose of having a threaded implementation since the main reactor-c thread does not execute reactions.

[erlingrj]

This looks good. Just some nitpicks about checking the return values from the Pico SDK. Also look into whether we need a recursive mutex. When getting threaded support for FlexPRET we ran into that issue and had to create a FlexPRET lock implementation that supported recursive calls.

[gundralaa]

looks good!

[sberkun]

@erlingrj just rebased onto the most recent changes in main, would be great if we could get this merged in

[lhstrh]

Whoops, @sberkun, it looks like we forgot to merge this, and it has fallen a bit behind. Sorry! Could you once again fix the merge conflicts?

[lhstrh]

We should get this merged, but there are some conflicts. Maybe @petervdonovan or @erlingrj could help?

[sberkun]

@lhstrh @erlingrj Sorry for the delay! This is once again ready for review.

[edwardalee]

LGTM! One comment included that we should not take as blocking the merge.

[sberkun]

@erlingrj looks like this is blocked because of requested changes; could you take a final look at this and unblock it?

[erlingrj]

Looks mostly good. But I have some questions about the cond bar implementation. I think the spurious wake-up problem in pthreads is not something we need to copy.