Improve complex type mismatch errors

[abs0luty]

Hi all,

Currently I'm working on #5062 to address #4578. When I first implemented the new diagnostics, I received feedback about wrapping in IDE settings:

---

In the discussion for the PR I shared a few different ways we might present complex type‑mismatch errors more clearly. The main options I've been looking at other than the one showed above are:

• Single error message with bullet points: instead of aligning caret markers under the original type expression, we would list each mismatch below a single message, e.g.:

  Box(#(#(Int, a), b, List(c)))
  
  Expected a to be Float, found String
  Expected b to be Float, found Int
  Expected c to be Float, found Int
  

  This approach avoids tricky alignment issues and wraps better in narrow views.

• Separate error messages for each argument: here we would emit a distinct error for each mismatched argument, showing only the problematic slice of the type each time.

  Box(#(#(Int, ...), Int, List(Int)))
  
  Expected type: Float
  Found type: String
  
  Box(#(#(Int, String), ..., List(Int)))
  
  Expected type: Float
  Found type: Int
  
  Box(#(#(Int, String), Int, List(...)))
  
  Expected type: Float
  Found type: Int
  

• Manual width control: by adding zero‑width spaces or breaking long type expressions into smaller lines ourselves, we can keep the caret markers aligned even when the type is lengthy.

  Box(
    #(
      #(Int, String),
             ^^^^^^ expected Float
      Int,
      ^^^ expected Float
      List(Int)
           ^^^ expected Float
    )
  )
  

Each option has trade‑offs in terms of readability and how well it works across different settings (terminal, VSCode, Zed, etc.). Before I go further, I’d really appreciate feedback from anyone following this PR: Which of these approaches do you think we should adopt for complex type‑mismatch errors? Are there other ideas we should explore?

[lpil]

I find the first 2 quite hard to read, but the third one is interesting. Do we know of a character that we would be able to use safely? I don't think LSP specifies any particular way that diagnostic text must be handled