build: add SENTRY_LIBUNWIND_SYSTEM option

[jpnurmi]

Add SENTRY_LIBUNWIND_SYSTEM as a Linux-only opt-in for using system libunwind via pkg-config instead of the vendored copy.

Verified with the Alpine CI builds:

-- Checking for module 'libunwind'
--   Found libunwind, version 1.8.1

Close: #1714

[uilianries]

LGTM ✅

[supervacuus]

This is fine, but it requires clear documentation under compile options in the README.

In this proposed setup, there is a dramatic asymmetry that this documentation should highlight:

• The vendored libunwind will always be built as a static archive and either linked into the resulting shared library or colocated with the other resulting static artifacts as output. This is what most Native SDK consumers will expect.
• when SENTRY_LIBUNWIND_SYSTEM=On, the decision of what kind of library artifact will be included is entirely deferred to the host distribution/sysroot/package manager. This path only considers SENTRY_BUILD_SHARED_LIBS in terms of how it makes an artifact available to a consuming CMake project, not in terms of how contained the resulting deployable install will be. The latter will have to be solved externally (either via a package manager configuration or through a very careful setup of packages on the build and target machines).

The latter, besides being different from the former, is also in stark contrast to what we had before we vendored libunwind as the default unwinder on Linux.

This is neither good nor bad, but it requires clear documentation of expectations, since it is now part of the build and package contract. The story is entirely different for users who can configure their build from within a source-level package manager like conan or vcpkg, and those who build and deploy against binary distro packages.

[linear-code]

NATIVE-187