feat: Add google-java-format and palantir-java-format support

[fredyw]

Integrates google-java-format and palantir-java-format support into the LSP proxy wrapper using a generic Formatter trait by intercepting document formatting requests at the LSP proxy layer.

Key architecture and features:

1. Introduces generic Formatter to allow future formatting backends to be plugged in easily.
2. Automatically downloads google-java-format binaries from GitHub Releases and palantir-java-format binaries from Maven Central.
3. Intercepts textDocument/formatting requests, retrieves the document from the cache, spawns the formatter command, and responds with the replaced document changes.
4. Add supports for runtime toggling and hot-swapping formatters dynamically by listening to configuration notifications.

[tartarughina]

Thanks for the PR but is this really needed?
JDTLS already offers the option to provide a .xml file describing how it should format the code.
This is for example how I've been handling my formats.

What are the benefits of including these two specific formatters?

[fredyw]

The XML option is basically using Eclipse formatter that tries to match Google Java Style or Palantir Java Style (fork of Google Java Format). It's an approximation and never 100% the same. Ideally when we code and when we run it in CI (using spotless for instance), we want the formatting to be 100% compatible to reduce friction for developers.

The option to use the Eclipse formatter still exists for those that prefer that. It's just an additional feature that I thought might benefit others.

[tartarughina]

I see, I assumed that the end result of those formatters was the xml then consumed by JDTLS.

Rather than integrating in the proxy the two formatters we could follow a different approach, similar to what Zed is doing with Ruff, for example.

https://github.com/zed-industries/zed/blob/e2e7a6769e693c843c82cea2dcf65917c139cc0f/assets/settings/default.json#L2261-L2272

    "Python": {
      "code_actions_on_format": {
        "source.organizeImports.ruff": true,
      },
      "formatter": {
        "language_server": {
          "name": "ruff",
        },
      },
      "debuggers": ["Debugpy"],
      "language_servers": ["basedpyright", "ruff", "!ty", "!pyrefly", "!pyright", "!pylsp", "..."],
    }

We vend from the extension the two LSP implementations wrapping the formatters and then the user, in order to enable them, uses the Java language settings, rather than the one for the extension, setting a different language server whose job is to format the code.

I see some clear benefits following this path:

1. this is the intended way to define formatters with Zed
2. clear separation between JDTLS and the different formatters
3. simpler logic, format requests are sent by Zed to the assigned formatter rather than being intercepted and redirected

I'm happy to further discuss about this.
@MrSubidubi, since you are the one with more experience, what is your take, or Zed's team generally speaking, onto this matter?