consider building libboost_stacktrace_backtrace

[SwooshyCueb]

Related: irods/irods#6146

Let's consider including libboost_stacktrace_backtrace in our boost packages.

For debian and ubuntu, the needed header and static library are included in the gcc dev package we (I think) already pull in with clang. We will have to tell boost's buildsystem where the header is, and maybe also where the library is, though.
For EL, we will have to build libbacktrace ourselves.

Given that we do not currently have a mechanism for per-platform build steps (nor do I wish to implement such functionality), I propose that, as part of boost's build process, we build libbacktrace ourselves, and bundle the header(s) and static library in our boost package. The static library (and probably the header(s) as well) is(are) only required if Boost.Stacktrace is used as a header-only library, which we currently do, but I think we should provide the capability to use Boost.Stacktrace as either a compiled library or a header-only library. Bundling our own libbacktrace will also allow us to use BOOST_STACKTRACE_BACKTRACE_FORCE_STATIC, should we deem it appropriate.

[SwooshyCueb]

OTOH, switching to using compiled versions of Boost.Stacktrace may require bumping the consortium number of the boost package, something I don't really like doing. This is because irods will link to the new library, and a dependency on a new boost package will ensure that the package dependency is not met by a package that does not contain the library. (This also applies to #253.) Therefore, it may make more sense to instead create a new externals package for libbacktrace.

[SwooshyCueb]

Let's check if and how EL, Ubuntu, and Debian package libboost_stacktrace_backtrace (I'm assuming EL does not) before we decide if/how to proceed. It is often a good idea to match how the distros do it.

[SwooshyCueb]

Looks like boost.stacktrace is packaged as shared libraries on all distros we support, and libboost_stacktrace_backtrace is only packaged for Debian and Ubuntu.