Port to Node-API: support Node.js 18 and later - #52

DBCAPI binds a NULL value of a multi-row bind as DT_NOTYPE with length 0
and other values with their own type, and the server rejects such a SQLDA
(-700 "SQLDA fields inconsistent for a multi-row SQLDA"). No bind layout
avoids it, so when a column mixes NULL and other values the rows are now
executed one at a time and the affected rows are summed. A savepoint keeps
the statement atomic: if a row fails, the rows before it are rolled back,
as a failing multi-row execution inserts nothing.

Also drop the batch size cached on prepared statements: sqlany_reset()
already sets the batch size back to 1, so executing a prepared statement
again with as many rows as before skipped sqlany_set_batch_size() and
silently inserted only the first row. It now calls it for every multi-row
execution, as upstream did, and fails with -182 instead: DBCAPI only
executes several rows again if there are more than before (README).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

DBCAPI's sqlany_reset() leaves room for one row in the SQLDA, and
sqlany_set_batch_size() only restores it when it has to grow the SQLDA,
so a prepared statement could only execute several rows again with more
rows than any earlier execution (error -182 otherwise).

Executions with several rows now use a second DBCAPI handle of the
statement, prepared on first use and never reset; single-row executions
keep resetting the main handle, which they need. Rows that leave
parameters unbound still go to the main handle, as the second one would
keep the bindings to an earlier execution's freed buffers.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

When a call passed fewer values than the statement has placeholders, or
none at all, the missing parameters were left unbound. The server takes
them as NULL, but then caches a plan that keeps them NULL: later
executions on the connection lost the values bound to those parameters,
also for a new prepared statement, conn.exec() and other INSERT
statements into the same table. A partial multi-row execution followed
by a full one of the same INSERT crashed dbsrv17 17.0.0.1063. Setting
max_plans_cached = 0 avoids both, and explicit NULL binds don't cause
them.

Missing values are now bound as NULL, so no input parameter stays
unbound and multi-row executions of prepared statements always use the
second handle. A procedure parameter that returns output stays unbound
without a value, as DBCAPI would write the output into the NULL's
missing buffer. A statement with placeholders executed without values
now runs with NULLs instead of failing with -188 for some statements.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

After sqlany_reset(), DBCAPI describes the IN parameters of a CALL that
also has OUT parameters as OUT ones. Binding a value to an OUT parameter
then crashed the process, and calls that left it out passed NULL for the
IN parameters. No handle is reset any more: every multi-row execution of
a prepared statement goes to the wide handle, so the main one only runs
single rows. OUT parameters are never bound, ignoring their values, and
INOUT ones are bound as input only, so DBCAPI never writes output into
the driver's buffers (or an earlier execution's freed ones).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

SQL Anywhere 16 fails INSERT INTO #calls (a, s) VALUES (a, ...) inside a
procedure whose parameter is also called a with -143 "Column 'a' not
found", even for a CALL without bind parameters. With distinct names the
test passes unchanged against a 16 server (SQLA 17.0.4 client, Node 22
and 24) as well as against 17.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>