This is a follow-up to the work outlined in this issue. While the work in that
issue focused around forwarding the DiagnosticCode and DiagnosticRelatedInformation, this issue is meant to track the work that is necessary to start utilizing the data field in the Diagnostic in order to forward quick fixes right from the compiler to your editor. Just to given an example, here a POC that was done during the Scala Tooling Summit showing a fix
coming from the compiler and being consumed from IntelliJ.

Like the other issue there are a fair amount of steps to start utilizing data in
this way. I've outlined the various steps below:

• Agree on the format that these should have. We talked about this at the Tooling Summit and also in the summit repo afterwards. The format that seems to make the most sense is to put it under an edits key which contains and array of WorkspaceEdits. This structure is now also being utilized by tools like
  scala-cli and other tools like Metals are ready to handle them. While this makes sense in BSP land, it's possible that it we could avoid some of the complexity that exists in the WorkspaceEdit and use a more minimal format in sbt-interface/compiler that later gets turned into a workspace edit later on.
  • Landed on a format that can be seen in here
• data (or whatever representation we have) needs to be added to Problem in sbt so that everything can use it.
  • feat: add in actions() to Problem sbt/sbt#7242
• Dotty will have to be update to use this new sbt interface when it's released.
  • feat: hook up actions in sbt-bridge to start forwarding actionable diagnostics #17561 (comment)
• build tools will need to make sure to forward it via BSP
  • build(deps): Update zinc from 1.8.1 to 1.9.1 scalacenter/bloop#2064
  • Forward ScalaDiagnostic sbt/sbt#7264
• We'll have to start utilizing the field to forward "quick fixes".
  • feat: account for ScalaDiagnostic in diagnostic data scalameta/metals#5338

Just to give a few examples, here are some candidates that came up during the discussions around this:

• implement all members
• add type for recursion automatically if possible
• auto import implicits
• add an import enabling a (experimental/compatibility/...) language feature - in some (most?) situations this could be alternatively achieved (globally rather than just in a single file) by adding a compiler option but this seems much more complicated as each build tool specifies compiler options in a different way and the compiler should be build tool agnostic
• add missing case clauses in a pattern match - E029
• remove redundant/disallowed keyword - E015, E037, E062, E063, E064, E065

I can update this as I get more details, but just creating this to start tracking progress on this.