Convert functions in `GHC.Tc.Utils.Monad` to take `TcRnMessage` as input

See also #19905 (the first point) and #18516.

In order to completely eradicate all the usages of UnknownTcRnMessage from GHC, we would need to tackle the functions inside GHC.Tc.Utils.Monad, namely:

• mkLongErrAt
• mkTcRnMessage
• addLongErrAt
• add_err_tcm
• addErrTcm
• addErrTc
• failWithTc
• failWithTcM
• ... (the list goes on)

All these functions construct, directly or indirectly, an UnknownTcRnMessage by taking an SDoc as input, which is not great. This task is potentially newcomer friendly, but the developer would probably require some guidance, because we would have to carefully untangle the zoo of logging functions from the GHC.Tc.Utils.Monad in favour of a more consistent API, or at least make sure that all these functions takes as input only TcRnMessages.

Doing such refactoring will inevitably trigger a cascade effect where now GHC will complain in every place where they are used. There are two strategies out of this:

1. Fix the usage sites of these functions by wrapping the (old) input SDoc with a TcRnUnknownMessage. This will just shift the "problem" elsewhere, but this is a good thing, because now it would be evident which are the remaining diagnostics which need porting, just by the virtue of a grep TcRnUnknownMessage. This means creating more newcomer friendly tickets to port those;

2. Go "all in" and complete the conversion of the messages while we do this refactoring, all in one glorious patch.

My recommendation would be (probably) to go with 1.. Yes, we might create more churning in the end, but it feels like the advantages would be A. more community/newcomers involvement and B. smaller MRs to review.