Replace unmaintained github.com/tmthrgd/go-hex with stdlib encoding/hex

github.com/tmthrgd/go-hex has been unmaintained for ~7 years (last commit 2019). We'd love to use bun but our SBOM/supply-chain scanning flags it as an abandoned dependency. Since bun uses only two API-compatible functions from it afaik, I'd like to propose to replace it with the standard go library encoding/hex.

Where it's used (quick search in the repo)

The dependency is imported in internal/hex.go - aliased as fasthex, using:

• fasthex.EncodedLen(...)
• fasthex.Encode(...) Every other hex reference in the codebase (again quick search in the repo) already uses stdlib encoding/hex. It's listed as a direct dependency in the root go.mod and as // indirect across the dialect/example modules.

Why we'd want to replace it

• It's currently unmaintained: if a defect/vulnerability were found, there's no upstream to patch it. (There are no known CVEs today — currently this is only a maintenance/supply-chain concern)
• A dependency could be droppen: rather than swapping one third-party lib for another - encoding/hex is maintained by the Go team and patched through normal Go releases.
• AFAIK it would be API- and behavior-compatible: EncodedLen and Encode have identical signatures and semantics, so the SQL output should be unchanged.

The only tradeoff I can see

go-hex provides SIMD-accelerated encoding, so stdlib encoding/hex may be slower when serializing large []byte/bytea blobs. I guess for most workloads this is is probably negligible, but maybe someone can include a benchmark on a representative blob size if maintainers want to quantify it before deciding.

Happy to open a PR if this direction is acceptable.