Remove go.work.sum from version control (#712)

I'd like to propose that we remove `go.work.sum` from version control.
I'd say in general going to workspaces has improved 95%+ of workflows,
but there are a couple annoying sharp edges. The main noticeable one is
that on any new release versions in `go.work.sum` get updated, forcing
the change to be checked in with a separate PR.

Reading more about `go.work.sum`, I found that the Go developers didn't
even bother to document it for two full years, only doing so reluctantly
earlier this year [1]. Its purpose is to track dependencies that are
used in the workspace but not part of any normal modules [2]:

> The go command will maintain a go.work.sum file that keeps track of
> hashes used by the workspace that are not in collective workspace
> modules’ go.sum files.

In River, only the modules, not the workspace, are public entities used
in other projects, and all of their builds are fully reproducible
because they all have `go.sum`. `go.work.sum` tracks some extra stuff,
but I don't think any of it is crucial to what River's users are
actually working with.

Furthermore, I learned that the Go docs actually recommend not checking
in `go.work` in many cases:

> It is generally inadvisable to commit go.work files into version
control systems, for two reasons:
>
> * A checked-in go.work file might override a developer’s own go.work
>   file from a parent directory, causing confusion when their use
>   directives don’t apply.
>
> * A checked-in go.work file may cause a continuous integration (CI)
>   system to select and thus test the wrong versions of a module’s
>   dependencies. CI systems should generally not be allowed to use the
>   go.work file so that they can test the behavior of the module as it
>   would be used when required by other modules, where a go.work file
>   within the module has no effect.
>
> That said, there are some cases where committing a go.work file makes
> sense. For example, when the modules in a repository are developed
> exclusively with each other but not together with external modules,
> there may not be a reason the developer would want to use a different
> combination of modules in a workspace. In that case, the module author
> should ensure the individual modules are tested and released properly.

I think the last paragraph applies more to River -- it's a clear UX
improvement and we're all working in a fairly consistent environment
without using any other external modules, but even so, if it's often
safe that a `go.work` could be omitted, I think there's a good argument
that `go.work.sum` could be omitted too.

I tried this in a branch and `go get`ing River from another test
project, and the removal of `go.work.sum` doesn't seem to have any
negative effect. I'd like to propose that we try removing it from Git
for a while and just see if there are any noticeable problems. I don't
think there will be, and this will purely be beneficial as it lets us
avoid needing to bump the file on every release,  but we can always add
it back in case that turns out to be wrong.

[1] golang/go#51941
[2] https://go.dev/ref/mod#workspaces

.gitignore

@@ -1,3 +1,4 @@
+/go.work.sum
 /river
 /internal/cmd/riverbench/riverbench
 /internal/cmd/testdbman/testdbman