fix: binding of COMP numeric host variables

[david-marconis]

Problem

A numeric host variable is always rendered to a decimal display string by SqlVar::createRealData (and parsed back by createCobolData), regardless of its COBOL USAGE. gixpp, however, sets CBL_FIELD_FLAG_BINARY for any USAGE BINARY item, including COMP integers, and every backend keys its parameter transmission on that flag:

Backend	binary branch
ODBC	SQL_C_BINARY
SQLite	sqlite3_bind_blob
PostgreSQL	binary format / OID_BYTEA
MySQL	MYSQL_TYPE_BLOB
Oracle	DPI_ORACLE_TYPE_BLOB

So a COMP host variable had its rendered ASCII digits ("42") transmitted as raw binary. Db2/ODBC rejects this with SQLSTATE 22003 ("numeric value out of range"); SQLite and the others silently bind a blob that never matches, so a lookup keyed on a COMP column returns no rows (SQLCODE 100). COMP-3 was unaffected only because gixpp does not flag it binary.

Fix

A single, backend-agnostic change in SqlVar:

• In the constructor, clear the binary flag for numeric types so every backend stays on the text path.
• Trim db_data_len for the COBOL_TYPE_*_BINARY cases so the trailing NULs left by snprintf in the length-sized buffer are not sent to the database.

Test

Adds TSQL044A (a COMP host variable used as a WHERE parameter and a FETCH target). It fails on the unfixed runtime and passes with the fix, across all configured backends.

old runtime:   SELECT SQLCODE: +0000000100   FLD2: 0000   -> fails
fixed runtime: SELECT SQLCODE: +0000000000   FLD2: 1234   -> passes

Verification

Checked against SQLite and Db2 (LUW, via unixODBC + the IBM clidriver): COMP, COMP-3, signed, V99 decimal, negative and 8-byte values all round-trip correctly as both WHERE-clause parameters and FETCH ... INTO targets.