This patch is part of a series that adds origin-tracking to the debugify
source location coverage checks, allowing us to report symbolized stack
traces of the point where missing source locations appear.

This patch adds a pair of new functions in `signals.h` that can be used
to collect and symbolize stack traces respectively. This has major
implementation overlap with the existing stack trace
collection/symbolizing methods, but the existing functions are
specialized for dumping a stack trace to stderr when LLVM crashes, while
these new functions are meant to be called repeatedly during the
execution of the program, and therefore we need a separate set of
functions.

In case of an error, the DL_info struct may have been left
uninitialized, so it is not safe to use its members.

In one error case, initialize dli_sname to nullptr explicitly, so that
the later check against nullptr is guaranteed to be safe.

Cygwin types sometimes do not match Linux exactly. Like in this case:
```
In file included from /h/projects/llvm-project/llvm/include/llvm/Support/Error.h:23,
                 from /h/projects/llvm-project/llvm/include/llvm/Support/FileSystem.h:34,
                 from /h/projects/llvm-project/llvm/lib/Support/Signals.cpp:22:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h: In instantiation of ‘llvm::format_object<Ts>::format_object(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:126:10:   required from ‘llvm::format_object<Ts ...> llvm::format(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’
/h/projects/llvm-project/llvm/lib/Support/Unix/Signals.inc:850:19:   required from here
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:106:34: error: no matching function for call to ‘std::tuple<int, char [4096]>::tuple(const int&, const char [4096])’
  106 |       : format_object_base(fmt), Vals(vals...) {
      |                                  ^~~~~~~~~~~~~
```
Casting here is safe and solves the issue.

Otherwise, the handler "swallows" the signal and the process continues
to execute. While this use case is peculiar, ignoring these signals
entirely seems more odd.

Prevents avoidable memory leaks.

Looks like exchange added in aa1333a91f8d8a060bcf5b14aa32a6e8bab74e8c
didn't take "continue" into account.

```
==llc==2150782==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 10 byte(s) in 1 object(s) allocated from:
    #0 0x5f1b0f9ac14a in strdup llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:593:3
    #1 0x5f1b1768428d in FileToRemoveList llvm-project/llvm/lib/Support/Unix/Signals.inc:105:55
```

Widely supported but missing on AIX
https://www.austingroupbugs.net/view.php?id=993

It is sufficient to just use `HAVE_DLOPEN`.

Pull Request: https://github.com/llvm/llvm-project/pull/123282

These are unneeded even on AIX, PURE_WINDOWS, and ZOS (per #104706)

* HAVE_ERRNO_H: introduced by 1a93330ffa2ae2aa0b49461f05e6f0d51e8443f8 (2009) but unneeded.
  The guarded ABI is unconditionally used by lldb.
* HAVE_FCNTL_H
* HAVE_FENV_H
* HAVE_SYS_STAT_H

Pull Request: https://github.com/llvm/llvm-project/pull/123087