Fix wrong values and lost parallelism in the pandas, numpy and Arrow input scans - #700

Input scan fixes for pandas, numpy and Arrow, found by comparing the 2.0 client with neo.

This PR makes duckdb read each pandas or numpy column as the array it holds at bind: its buffer, length, dtype and mask. Some fixes change behavior.

Currently:

• a sliced nullable column moves its NULLs, and masked numpy elements read as values.
• a registered dict whose array shrank is read past its end, and a non str key fails with std::bad_cast.
• count(*) converts the first column, which can fail the query.
• reading back a fetchnumpy result with NULL strings hangs.
• a duckdb.Value in an object column invalidates the database.
• pyarrow string columns fail on pandas 2, and on pandas 3 become Python objects at every bind.
• a one chunk Arrow source scans on one thread.

With this PR, bind reads each column once and checks it against one row count: Column 'b' has 2 rows where 'a' has 5. Masked elements read NULL, count(*) reads no column, pyarrow strings are read as Arrow without the GIL, and the Arrow scan splits batches into 122880 row ranges, so one chunk uses every thread. Unordered results from such a source can now vary.

Benchmarks (instructions): suite geomean 0.69x, 0 slower; a 2M row str column 0.30x; count(*) over a str frame 0.01x. A 10 percent masked array costs 1.63x: the base ignored masks.

Notes:

• input that misreports itself, like an ndarray subclass whose shape lies, is out of scope.
• a duckdb.Value with a str type name can still hang against a bind on the default connection, as on the base (strict xfail).

Next PR:

• exact conversion of object values outside the analyzer's sample. it needs declared types for con.append and Spark, so it waits for the relational API rework.