Better thought out caching mechanism that actually works

[brandur]

This one follows up #794 again. That change included a template cache,
with the idea being that we could reuse a rendered sqlc query when all
input values were expected to be stable. For example, when replacing
something like a schema name, we'd presumably always be replacing the
template value with the same schema over and over again, so it'd be
better to save on the work.

But that caching system hadn't adequately been thought through, and
wouldn't really work. I realized when I was putting #798 (explicit
schemas) together that if you injected two schema values from two
different clients then you'd end up using the same cache value, which is
wrong.

Here, we tool out the cache layer a little more so that it considers
input values and named args, which all must be consistent for a cached
value to be returned. We also add tests to make sure of it.

Building a cache key unfortunately has to rely on concatenating some
strings together and presorting map keys for stability, but even with
the extra work involved, a cache hit still comes out to be quite a bit
faster than a miss (~2.5x faster), so it seems worth doing:

$ go test ./rivershared/sqlctemplate -bench=.
goos: darwin
goarch: arm64
pkg: github.com/riverqueue/river/rivershared/sqlctemplate
cpu: Apple M4
BenchmarkReplacer/WithCache-10           1626988               735.7 ns/op
BenchmarkReplacer/WithoutCache-10         695517              1710 ns/op
PASS
ok      github.com/riverqueue/river/rivershared/sqlctemplate    3.419s

[bgentry]

Looks solid, good catch on this.

[brandur]

ty man.