refactor(internal): replace unmaintained go-hex with stdlib encoding/hex

[donn-duinn]

Closes #1385.

Motivation

github.com/tmthrgd/go-hex has been unmaintained since 2019. As noted in #1385, SBOM / supply-chain scanners flag bun as depending on an abandoned package. bun uses only two functions from it, both of which are drop-in equivalents of the standard library.

Change

• internal/hex.go used only EncodedLen and Encode. Both have identical signatures and semantics in encoding/hex, so the emitted SQL (x… byte literals) is byte-for-byte unchanged. Swapped the alias import for encoding/hex and updated the two call sites.
• Ran go mod tidy in every module so the now-unused dependency is dropped from all go.mod / go.sum files (it was a direct dep in the root module and // indirect across the dialect/driver/extra/example modules). Where go-hex was the sole importer of its transitive golang.org/x/sys, tidy removes that too.

Net result: an abandoned dependency (and one orphaned transitive) is removed with zero additions — every changed line in a go.mod/go.sum is a deletion.

Trade-off

go-hex provided SIMD-accelerated encoding, so encoding/hex may be marginally slower when serialising very large []byte/bytea blobs. For typical workloads this is negligible, and the standard library is maintained and patched through normal Go releases. Happy to add a benchmark if you would like to quantify it.

Verification

• go build ./... and go vet ./... pass in the root module, all dialect/*, driver/pgdriver, dbfixture, all extra/*, and sampled example/* modules.
• go test ./internal/... ./schema/... pass (this is the path that exercises HexEncoder via schema/append_value.go).
• Verified the HexEncoder output is byte-identical to the previous implementation across empty, single-byte, and multi-byte inputs (including 0x00/0xff).
• Confirmed 0 remaining references to go-hex/fasthex anywhere in the tree, and that no go/toolchain directives or unrelated dependency versions changed.