haddock: Use the more precise SDocContext instead of DynFlags

The pervasive usage of DynFlags (the parsed command-line options passed to ghc) blurs the border between different components of Haddock, and especially those that focus solely on printing text on the screen.

In order to improve the understanding of the real dependencies of a function, the pretty-printer options are made concrete earlier in the pipeline instead of late when pretty-printing happens.

This also has the advantage of clarifying which functions actually require DynFlags for purposes other than pretty-printing, thus making the interactions between Haddock and GHC more understandable when exploring the code base.

See Henry, Ericson, Young. "Modularizing GHC". https://hsyl20.fr/home/files/papers/2022-ghc-modularity.pdf. 2022

• if your MR may break existing programs (e.g. touches base or causes the compiler to reject programs), please describe the expected breakage and add the user-facing label. This will run ghc/head.hackage> to characterise the effect of your change on Hackage.
• ensure that your commits are either individually buildable or squashed
• ensure that your commit messages describe what they do (referring to tickets using #NNNN syntax when appropriate)
• have added source comments describing your change. For larger changes you likely should add a [Note][notes] and cross-reference it from the relevant places.
• add a [testcase to the testsuite][adding test].
• updates the users guide if applicable
• mentions new features in the release notes for the next release