Introduce ThrownBy exception annotation

In concurrent programs asynchronous exceptions can result in non-trivial action-at-a-distance, resulting in hard-to-reason-about control flow in exceptional situations. This leads to challenging debugging scenarios which GHC/Haskell currently offers few good tools to characterize.

However, the exception annotation mechanism provides a reasonable path to improving this situation. Specifically, a new variety of `ExceptionAnnotation`:
```haskell
module Control.Exception where

newtype ThrownFrom = ThrownFrom Backtraces

instance Show ThrownFrom
instance ExceptionAnnotation ThrownFrom
```

`Control.Exception.throwTo` to be implemented as follows:
```haskell
throwTo :: Exception e => ThreadId -> e -> IO ()
throwTo (ThreadId tid) ex
| backtraceDesired ex = do
bts <- ThrownFrom <$> collectBacktraces
throwTo_ $ addExceptionContext bts $ toException ex
| otherwise =
throwTo_ $ toException ex

throwTo_ :: Exception e => ThreadId -> e -> IO ()
throwTo_ (ThreadId tid) ex = IO $ \ s ->
case (killThread# tid ex' s) of s1 -> (# s1, () #)
```

This gives the developer a clear chain of causality between their thread dying and the exception from which the death stemmed.

MR is https://gitlab.haskell.org/ghc/ghc/-/merge_requests/16273

Start with the Control.Exception module and its throwTo entry point, then read merge request 16273 for the current implementation context. Check how ThrownFrom and ExceptionAnnotation fit the proposed exception flow; done means asynchronous exceptions expose the requested causal chain without changing the stated fallback behavior.

Written by the indexing model from the issue text.