Avoid unnecessary recompilation due to -haddock

[fendor]

Due to unprincipled adding and removing the -haddock flag during compilation and recompilation checking, we were performing more work than necessary. We avoid this by compiling everything with -haddock by default. This is safe nowadays, we have essentially been doing this for many releases, and know this is fine. For the occasion where we actually want to parse without the -haddock flag, we keep explicitly disabling it.

We enable -haddock flag during session loading, since we already perform a number of DynFlags tweaks. This behaviour is dependent on the OptHaddockParse opton, which can, currently, only be modified at compile-time.

Closes #4511

[fendor]

I would love to implement a regression test for this, but I am currently unsure how.

[fendor]

I manually tested it on GHC and think I can confirm this fixes the recompilation issue but I struggle to come up with a test case in HLS itself.

[cassandracomar]

possible issue with this PR -- the haddocks for definitions in the local module don't appear to be available in the completion details. I instead see:

2025-06-02T17:03:10.743161Z | Warning | No plugin handles this "completionItem/resolve" request.

in the lsp server's log output. non-local details DO appear to be resolvable, however, and that warning isn't printed. if I just use master instead of applying this PR, this warning is never printed for either local or non-local bindings.

[fendor]

Thank you for testing this change! I will look into it.

[fendor]

Can't reproduce, with GHC 9.6.7, I get:

and the logs are clear.

[fendor]

I am unsure how to test this, I manually verified that the behaviour reported in #4511 doesn't seem to be occurring in GHC.

Are we fine with merging this as is?