c,go,java: provide a driver 'framework' or 'base' instead of entirely separate drivers

[lidavidm]

All the drivers in a language need to follow the same specifications, the same conventions, and have a lot of similar scaffolding. For maintainability's and testing's sake it may make more sense to create base drivers that handle most of the ADBC state and API boundaries and just dispatch to a vendor-specific backend to do things like query execution. We only have SQLite and PostgreSQL for now, but I expect we'll have an ODBC adapter soon. And it seems like the drivers may want more similar functionality than we expect: PostgreSQL decimals, for instance, will likely need type inference in the same way all SQLite type do, if we want to actually convert them to decimals.

It would also make it easier to integrate observability features like detailed logging, OpenTelemetry support, and so on, if we can (mostly) handle them in one place.

Admittedly, a lot of the code is actually in the query execution part, which may not be (easily) shareable. So it may not be as easy of a win as I think.

• c/driver: evaluate C++ backports library #1101
• feat(c/driver/common): Add minimal C++ driver framework #1539
• go: provide a driver 'framework' or 'base' instead of entirely separate drivers #996
• go: extend driver framework to cover connections #1105
• go: provide trace logs in driver framework #1104

[lidavidm]

In particular, @ywc88 was trying to figure out how best to test #910. If we had a logging framework set up, I think it would have made the most sense to log executed queries/transaction state and inspect that for the unit test, which would let us directly verify driver interactions (much in the same way @paleolimbot's R design lets us validate how R API calls translate into C API calls, which is quite slick).

[paleolimbot]

This would be very helpful and would also probably increase the probability that others' will write actually write drivers...the scafolding is quite verbose (for good reason...database drivers are hard and the C linking is worth it). At their core, ADBC drivers are "string in record batch stream out" and it would be nice if implementing a driver could minimally be implementing that one function with a driver init function of InitDriver<DriverClass, DatabaseClass, ConnectionClass, StatementClass>(void* raw_driver, int version).

[lidavidm]

My problem with doing this right this moment is conflicting with the v1.1.0 work...I'll probably plan to start the refactor after 1.1.0 lands, then.

[lidavidm]

And then adapting turbodbc to this would be a good first test.