format: better support for code generating clients

[lidavidm]

• Provide a way to quote a name or a string with the backend-specific syntax (instead of requiring clients to introspect metadata)
• Provide a way to introspect the database type name for a given Arrow type, particularly for what the driver will do in scenarios like bulk ingestion (could do this by: binding an empty batch with a schema, then setting an option on the statement before "executing" it to get the results)
• Provide a way to generate the name of a bind parameter by index or by name

See mentioned issues below for motivations.

[paleolimbot]

It should also be said that the fact that SQL generation is so closely linked to driver implementations might be R-specific: dbplyr is the only SQL generator in town and it dispatches a number of things on the class of the "driver", which it assumes is a DBI driver. Some backend-specific behaviour is hard-coded in dbplyr and other parts dispatch on the driver class.

I'm not all that familiar with how it works in Python, but I think Python's SQL generation game is not coupled with dbapi in quite the same way or at all. This is arguably a much better design and it may be that improving the ecosystem on the R side is a more worthwhile exercise than codifying driver quirks in a C-stable API.

I imagine that even with an improved ecosystem, we'll need something from the driver beyond an info string. I wonder if something like AdbcConnectionCallMethod(AdbcConnection*, const char* method_name, ArrowArrayStream* input, ArrowArrayStream* output); could mitigate the need for adding functions to the header.

[lidavidm]

The earliest drafts used a similar design where you requested function pointers by name, but that's very inconvenient to use.

[lidavidm]

Much of the current design was a concession to requests to be able to use the API directly and not have to pull in the driver manager.

[paleolimbot]

I envision it as an escape hatch for uncommonly-used methods that are only applicable to higher-level APIs or only relevant for some backends. (No pressure if it's not the right fit for this problem).

[lidavidm]

All three of the above could be implemented via existing methods if that's the concern