Template Haskell and system C++ libraries

**Describe the bug**

`extra-libraries` for widely ported cabal packages are hard to maintain across platforms and over time.

**To Reproduce**

This is best illustrated with a [story of one change](https://github.com/haskell/text/issues/398) in `text`. The C++ code there needed to be linked against system C++ libraries. This required system-based branching which is currently incomplete and already outdated. It [was even worse](https://github.com/haskell/text/pull/403/files). It is outdated because since I landed my change OpenBSD moved to clang 13. This changed the set of required libraries to be `c++ c++abi pthread`, and indeed with this change the tests pass.

The root of the problem is `cabal` not having visibility into the system compiler which [enumerates the libraries above](https://github.com/openbsd/src/blob/a0747c9f67a4ae71ccb71e62a28d1ea19e06a63c/gnu/llvm/clang/lib/Driver/ToolChains/OpenBSD.cpp#L305-L307). It is maintained as part of the system evolution.

I could add a couple of tokens to `text.cabal` and hope that I don't have to change them again soon, but experience shows that a compiler upgrade is all it takes. Things become intractable if I wanted to support multiple OS releases (unless there's a version-conditional I'm missing?)

**Expected behavior**

Linking with C++ code doesn't require reproducing the details of different operating systems over time in all packages.

**System information**
- Operating system: Variety
- `cabal`, `ghc` versions

Start by reading the issue's linked text change and its text.cabal configuration, then compare the OpenBSD Clang library-enumeration code referenced in the report. Trace how Cabal handles compiler-selected system libraries across platforms. Done means C++-linking packages no longer need to reproduce changing OS and compiler library details in each package.

Written by the indexing model from the issue text.