Fix pdo_odbc output-buffer leak and stale-binding out-of-bounds read

[iliaal]

pdo_odbc bound each parameter with SQLBindParameter at PDO_PARAM_EVT_ALLOC, recording deferred pointers (P->outbuf for output, &P->len, and the bound-parameter struct itself for input) into the ODBC statement, and never freed P->outbuf. Both outlive the bound-parameter struct, which PDO destroys mid-statement when execute() is given an array or a position is rebound, so the output buffer leaked and the stale binding made the next SQLExecute read freed memory. This tracks the output buffers on the statement and frees them in the destructor after SQLFreeHandle, and defers SQLBindParameter to execute time, rebinding the current parameters when the parameter set has changed.

Reproducers, both under a debug or ASAN build:

// out-of-bounds read (freed length indicator drives a wild over-read)
$stmt = $pdo->prepare('SELECT ? AS v');
$v = 'x';
$stmt->bindParam(1, $v, PDO::PARAM_STR | PDO::PARAM_INPUT_OUTPUT, 256);
$stmt->execute([]);

// leak of the output buffer
$stmt = $pdo->prepare('SELECT ? AS v');
$stmt->bindParam(1, $v, PDO::PARAM_STR | PDO::PARAM_INPUT_OUTPUT, 256);
$stmt->execute();

[NattyNarwhal]

Initial pass, looks good other than a few nitpicky things related to clarity.

[NattyNarwhal]

If 8 is supposed to be pointer size, it should be using sizeof to make that clear

[iliaal]

That's zend_hash_init's nSize (initial table size), not a pointer size, so sizeof doesn't apply.

[NattyNarwhal]

My misread there. That said, I'm still not a huge fan of the magic number here, if it's a guess on the typical high end of param count, we should be clear here; a lot of instances of zend_hash_init are not. (Oh, and persistent param at end should also probably be false since it's a bool param, but that's not consistent through most of the codebase... opportunity for cleanup?)

[iliaal]

Changed the persistent flag to false and replaced the 8 with HT_MIN_SIZE to make the minimum-table intent explicit.

[NattyNarwhal]

Seems OK to me now