Add DLL and ARM64 builds to MinGW workflow

[tobiasherzke]

Extension of existing Msys2 MinGW workflow to also build liblsl as a DLL, and to also build for the Windows ARM64 target.

For openMHA, I would need a MinGW-compiled liblsl as DLL rather than as static library.

This pull request is divided into two commits:

The first commit extends the existing MinGW build matrix to support DLL builds and the Msys2 "clangarm64" target.

The second commit extends the same workflow in order to add these artifacts to releases.

I had to disable running the unit tests for the "clangarm64" target, as the tests would cause segfaults. Using the compiled clangarm64 liblsl DLL as a dependency for openMHA on Windows ARM64, however, worked fine for me.

[cboulay]

Thanks @tobiasherzke. We dug into the clangarm64 unit-test segfault to decide whether it's safe to skip. Summary of what we found (reproduced on a throwaway diagnostic workflow running the windows-11-arm + MSYS2 clangarm64 build, both DLL and static):

Root cause: an upstream LLVM-MinGW aarch64 thread_local/TLS limitation, not a liblsl bug.

A symbolized lldb backtrace shows the crash on the first async socket operation, when an outlet starts serving:

#0 asio call_stack<thread_context,thread_info_base>::top()   call_stack.hpp:108  <- access violation
#1 asio thread_context::top_of_thread_call_stack()           thread_context.ipp:27
#2 asio recycling_allocator::allocate()  (async_accept handler alloc)
...
#9  lsl::tcp_server::accept_next_connection()  tcp_server.cpp:218
#10 lsl::tcp_server::begin_serving()           tcp_server.cpp:189
#11 lsl::stream_outlet_impl::stream_outlet_impl() stream_outlet_impl.cpp:51

asio stores its per-thread call stack in a static thread_local pointer (call_stack::top_); reading that TLS slot access-violates on this toolchain. liblsl/asio use a completely standard thread_local here, so there's nothing to fix on our side.

Partial mitigation: forcing native Windows TLS with -fno-emulated-tls fixes the in-module path — tcpserver and most internal tests then pass, leaving only the 4 cancellable_streambuf cancellation tests crashing. But the exported (public C API) tests still crash at the first outlet creation across the DLL boundary, which is the known Windows-on-ARM MinGW TLS-across-DLL weakness. No liblsl-side flag closes that gap.

Conclusion: disabling the tests on clangarm64 is justified — they're catching a toolchain miscompilation, not a library defect — and it's consistent with your report that the DLL works fine as an openMHA dependency (real-app usage doesn't stress the same rapid cross-DLL init/cancellation path the suite hammers).

We're parking the build-matrix decision for now rather than merging immediately, but wanted to record this so the test-skip is a documented, understood choice. When we pick this back up, the suggestion would be to keep the clangarm64 artifacts with tests skipped (ideally with a comment pointing here + a TODO to revisit as the toolchain matures), and consider adding -fno-emulated-tls.