chore(c/validation): add quirk for identifier quoting

[fornwall]

Add a identifier quoting hook whose default reproduces the current ANSI double-quoted identifier quoting.

Existing drivers are unaffected - new drivers for databases not supporting double quotes for identifiers (such as GoogleSQL ones, which use backticks) can override the hook.

This mirrors what the adbc-drivers/driverbase-go validation harness does through its optional TableQuoter interface, which also defaults to ANSI double quotes.

[fornwall]

How come we sometimes have .c_str() and sometimes not? (Maybe we should just bring in std::string_literals?)

The reason for c_str() here is that we're using the ADBC C API, as in AdbcStatementSetSqlQuery, which takes the query as const char*:

AdbcStatusCode AdbcStatementSetSqlQuery(struct AdbcStatement* statement,
                                        const char* query, struct AdbcError* error);

This contrasts to the validation suite internal functions, which is C++ and takes strings or string views.

Given that, I don't think std::string_literals would help here - that helps with reducing syntactic overhead for literals that should be strings (std::string("mystring") -> "mystring"s), but not the other way around.

One thing we could do here to perhaps reduce noice is extracting the query into a variable, like:

  ASSERT_THAT(AdbcStatementSetSqlQuery(
                  &statement,
                  ("SELECT * FROM " + quirks()->QuoteIdentifier("bulk_ingest") +
                   " ORDER BY " + quirks()->QuoteIdentifier("col") + " ASC NULLS FIRST")
                      .c_str(),
                  &error),
              IsOkStatus(&error));

->

  std::string query = ("SELECT * FROM " + quirks()->QuoteIdentifier("bulk_ingest") +
                   " ORDER BY " + quirks()->QuoteIdentifier("col") + " ASC NULLS FIRST");
  ASSERT_THAT(AdbcStatementSetSqlQuery(&statement, query.c_str(), &error),
              IsOkStatus(&error));

Should I do that here?

[lidavidm]

ah you're right, I was scrolling too quickly and thought we were using it inside the concat instead of outside

[lidavidm]

What I think I actually want is to upgrade to C++20 so we can use std::format but for now I think this is OK

[fornwall]

What I think I actually want is to upgrade to C++20 so we can use std::format

It's probably a good time, right? Created #4506 for that.

I can update to use std::format after that transtion is done (but as you say, I think this one can be merged, and then the code can be updated once C++20 is in).