Use binary COPY for flex and middle tables

[leijurv]

Fixes #2286

This PR switches the Postgres COPY for the middle tables and most flex tables from the textual format to the binary format. This is a moderate win in decreasing CPU time that is otherwise spent on int-to-text-to-int, float-to-text-to-float, WKB hex, etc.

Details:

• Each db_target_descr_t knows the binary versions of its column types, if present db_copy_mgr_t will seamlessly switch to binary format for the same calls (add_column, new_array, etc)
• Binary mode checks each field's type from the list, asserting that it matches
• Middle tables will always use binary mode. In particular, int8[] is supported, to make this possible.
• Flex tables use binary mode if they only use the following types: text, boolean, int2/4/8, real, double precision, hstore, json, jsonb, direction, id columns, and all geometry types. It will fall back to text mode if user-defined SQL types are present, or if there is timestamp/timestamptz directly from Lua as an arbitrary string. While I could have supported that last possibility, there is a better alternative (Use timestamp column type in example configs #2502) that doesn't require complicated timestamp parsing code.
• Pgsql output and gen are unchanged, still text.
• Replace geometry check trigger by WHERE condition on COPY #2500 is supported

Changes to behavior:

• No change for integers, doubles, text, json, hstore, arrays, timestamps, or WKB from OSM data.
• If the Lua gives a double which is stored in PG as a real, currently text mode implicitly does fp64 -> text -> fp32. This causes rounding to happen twice. Binary mode will now round fp64 -> fp32 directly. Of course, one could reimplement the double rounding behavior, but I don't think this is good behavior to preserve. The effect is at most 1 ULP of difference, and it only happens when a fp64 landed exactly halfway between two fp32 values, which is extremely unlikely. A potential place where this could theoretically arise is in way_area - but in practice, there are none, in the full current planet, that have any difference here, and there probably never will be, as less than 1 in a billion doubles are like this. Out of range values like inf remain an error as in text mode.

Testing:

• Lots of tests in test-db-copy-mgr.cpp
• All ctest and BDD pass
• Tested all examples in flex-config, and also osm carto. Imported with --slim -x and then updated with an .osc. (this is what exposed Fix reading attributes of nodes from the middle #2501). All table contents identical to master.

Performance:

• Ryzen 9 3900X, Samsung 970 EVO Plus NVMe, Postgres 18.6, PostGIS 3.6.4
• OSM Carto flex style. Nodes cached in RAM (no flat nodes.bin).
• Cold restart every time
• Alternating runs between this branch and master, taking the median of seven.

Extract (from geofabrik)	Flags	Wall clock time	Postgres CPU, import phase	Postgres CPU, total	osm2pgsql CPU
Delaware	--slim	12.74 -> 12.36 s (−3.0%)	7.45 -> 6.44 s (−13.6%)	13.03 -> 12.03 s (−7.7%)	6.92 -> 6.59 s (−4.8%)
Delaware	--slim --drop	12.36 -> 12.02 s (−2.8%)	6.64 -> 5.69 s (−14.3%)	9.00 -> 8.05 s (−10.6%)	6.89 -> 6.57 s (−4.6%)
New Jersey	--slim	83.81 -> 80.37 s (−4.1%)	47.66 -> 41.17 s (−13.6%)	86.74 -> 80.13 s (−7.6%)	48.11 -> 45.73 s (−4.9%)

So as we can see Postgres spends about 14% less CPU to ingest. The overall win to wall clock time is currently not so much because we are bottlenecked by the single threaded Lua processing time. The benefit from this PR is larger when combined with upcoming PRs... (teaser post credit scene 😺)