Exceptions are not always propagated to client code

[kyllingstad]

It seems that proxy-fmu spawns one or more worker threads to perform some of its operations, and exceptions that are thrown within these threads are not handled properly.

I'm not familiar enough with the proxy-fmu API to provide a minimal test case. I discovered this when running the cosim CLI. Here is one way to reproduce it:

1. Make sure that cosim CLI is available and compiled with proxy-fmu support.
2. Delete/rename/move the proxyfmu executable so that the program can't find it.
3. Run cosim run path/to/OspSystemStructure.xml, where the system structure file is one that uses proxyfmu (for example this one).

Observe the following output (on Linux):

terminate called after throwing an instance of 'std::runtime_error'
  what():  [proxyfmu] No proxyfmu executable found. [path redacted]/bin/proxyfmu does not exist!
Aborted (core dumped)  cosim run OspSystemStructure.xm

Using GDB, I've observed that the exception originates in a worker thread and is never caught before it propagates to the thread entry point and causes the C++ runtime to call std::terminate().

Instead, there should be some mechanism to capture the exception, pass it to the main thread, and rethrow it there, enabling the whole program to exit gracefully.