harry/move go binary and deps

[harrisoncramer]

Updates Go to 1.25.1 and updates Go packages to new Gitlab location.

This will be a Major version bump, since it requires users to update their Go versions.

Upgrade Steps

The plugin now includes a /version endpoint which returns the version of the Go binary. The binary's version is baked in when it's built as the last git tag which is what we use for releases. When a user upgrades their plugin, the next time the server starts:

• The lua code will call this version endpoint.
• The version endpoint will respond with the last version the binary was built with (for most users this will be a 404 for now, since this is a new endpoint)
• The Lua code will see a mismatch between this version and the version that it's supposed to see, and rebuild the binary

The next time the user starts the server, the /version endpoint will return the tag version that matches Lua, and no rebuild and restart will occur. This should ensure that all users have the latest version of the binary on their machine that's linked to the Lua code. Whenever they upgrade the plugin, gitlab.nvim will rebuild the Go binary whenever the server notices a mismatch.

[harrisoncramer]

@jakubbortlik This seems to work for me, if you wouldn't mind trying the upgrade path that'd be helpful.

Basically, however you have this plugin pinned/installed locally, change the branch to this version. Ideally (if you are running an older version of Go) you should see a failure. If you upgrade Go, and try to run the plugin, it should auto re-compile the server. Then subsequent restarts wouldn't recompile.

Please review this PR when you get a chance, I can merge it after you've confirmed the upgrade path. We will use this approach moving forward -- any new release will generate a tag which is baked into the Go binary, which ensures that folks' Go code is recompiled on any changes to the plugin, since it's tag-based.