Preserve type for binary protocol parameters in prepared statements

[ramnes]

When bindStmtArgs parses binary protocol parameters, the MySQL type is available in paramTypes. However, the library loses this type information when passing the parsed values to the Handler.HandleStmtExecute callback: it converts length-encoded parameters (datetime, varchar, blob, etc.) to plain []byte and drops the type.

This creates problems for proxies: when forwarding these parameters to a backend, the client sees []byte and sends them as MYSQL_TYPE_STRING, even if the original type was MYSQL_TYPE_DATETIME or another type. Some server implementations strictly validate parameter types and reject this mismatch.

This PR introduces a simple TypedBytes struct that preserves the original MySQL type alongside the raw bytes. Handler.HandleStmtExecute callback now receives this struct instead of []byte for length-encoded parameters, and client.Stmt also handles TypedBytes by using the preserved type when sending to servers.

[lance6716]

should we directly use v.Bytes? Why need to encode it again

[ramnes]

LengthEncodedString in server/stmt.go strips the length prefix when parsing. v.Bytes contains only the raw data, so we need to re-add the length prefix when sending.