Valkey SDK cache/db support

### Problem Statement

Like in case of [GO-95](https://linear.app/getsentry/issue/GO-95/databasesql-integration) sentry should have a sub package implementation for valkey/redis kind of databases, which should support cache and db behavior for insights modules. (Basically on the Backend tab we should be able to see and use these metrics not just in Traces)

### Solution Brainstorm

Honestly I have a working POC for valkey already.
Luckily valkey exposes a hook: [https://github.com/valkey-io/valkey-go/tree/main/valkeyhook]() for instrumentation purposes.

Also since valkey-go is a fork of [rueidis]() we can use the same hook implementation with that client too.

Next we have to make the traces compliant with [https://develop.sentry.dev/sdk/telemetry/traces/modules/caches/]() and [https://develop.sentry.dev/sdk/telemetry/traces/modules/queries/]() and [https://develop.sentry.dev/sdk/telemetry/traces/sql-transactions/]() (for the multi command)

Following a config pattern like this: [https://github.com/getsentry/sentry-go/blob/master/http/sentryhttp.go]()

I've ended up in my POC with the following public interface:

```go
err := sentry.Init(sentry.ClientOptions{
Dsn: os.Getenv("SENTRY_DSN"),
TracesSampleRate: 1.0,
EnableTracing: true,
AttachStacktrace: true,
})
if err != nil {
log.Fatalf("sentry.Init: %s", err)
}

defer sentry.Flush(2 * time.Second)

// Create a valkey client
dbClient, err := valkey.NewClient(valkey.ClientOption{
InitAddress: []string{"localhost:6379"},
})

if err != nil {
log.Fatalf("valkey.NewClient (db): %s", err)
}

// The sentryvalkey.Type can be either DB or Cache, so you can switch it up per use case.
// Here we wrap valkey client with a custom hook that implements the `valkeyhook.Hook` interface
dbClient = valkeyhook.WithHook(dbClient, sentryvalkey.New(sentryvalkey.Options{
Type: sentryvalkey.TypeDB,
}))
defer dbClient.Close()
```

Also I'm more than happy to finalize and make this implementation production ready and contribute/maintain this, since we are already using this.

It expose traces like this, which are perfectly capable to be parsed by the caching layer:

(Currently the DB layer is kinda buggy, it cannot show query descriptions, but it can parse QPS and every other variable.)