Is your feature request related to a problem? Please describe.
SQLite supported the use of double-quoted strings in string literals, to help match some old MySQL behavior. The SQL standard specifies that string literals should be single quoted, and column names double quoted.

The SQLite docs explain this, and how in hindsight it was a bad decision. But, changing is breaking for a lot of applications. They recommend building with SQLITE_DQS=0.
https://www.sqlite.org/quirks.html#dblquote
https://www.sqlite.org/compile.html#dqs

Recently, conda-forge's sqlite 3.49.0/3.49.1 changed the build option to SQLITE_DQS=0, breaking our builds.
For the 8.4 release branch, #5186 pinned to a previous version.
For the main branch, #5196 cherry picks the change

Describe the solution you'd like

Adapt the code, users, and tests to not need #5196 anymore, and revert that PR (unpin the conda dependency).

Describe alternatives you've considered
Wait for more breakages as that time will come for other platforms too.

Additional context
Add any other context or screenshots about the feature request here.

From their page https://www.sqlite.org/quirks.html#dblquote :

8. Double-quoted String Literals Are Accepted

The SQL standard requires double-quotes around identifiers and single-quotes around string literals. For example:

• "this is a legal SQL column name"
• 'this is an SQL string literal'

SQLite accepts both of the above. But, in an effort to be compatible with MySQL 3.x (which was one of the most widely used RDBMSes when SQLite was first being designed) SQLite will also interpret a double-quotes string as string literal if it does not match any valid identifier.

This misfeature means that a misspelled double-quoted identifier will be interpreted as a string literal, rather than generating an error. It also lures developers who are new to the SQL language into the bad habit of using double-quoted string literals when they really need to learn to use the correct single-quoted string literal form.

In hindsight, we should not have tried to make SQLite accept MySQL 3.x syntax, and should have never allowed double-quoted string literals. However, there are countless applications that make use of double-quoted string literals and so we continue to support that capability to avoid breaking legacy.

As of SQLite 3.27.0 (2019-02-07) the use of a double-quoted string literal causes a warning message to be sent to the error log.

As of SQLite 3.29.0 (2019-07-10) the use of double-quoted string literals can be disabled at run-time using the SQLITE_DBCONFIG_DQS_DDL and SQLITE_DBCONFIG_DQS_DML actions to sqlite3_db_config(). The default settings can be altered at compile-time using the -DSQLITE_DQS=N compile-time option. Application developers are encouraged to compile using -DSQLITE_DQS=0 in order to disable the double-quoted string literal misfeature by default. If that is not possible, then disable double-quoted string literals for individual database connections using C-code like this:

sqlite3_db_config(db, SQLITE_DBCONFIG_DQS_DDL, 0, (void*)0);
sqlite3_db_config(db, SQLITE_DBCONFIG_DQS_DML, 0, (void*)0);
Or, if double-quoted string literals are disabled by default, but need to be selectively enabled for some historical database connections, that can be done using the same C-code as shown above except with the third parameter changed from 0 to 1.

As of SQLite 3.41.0 (2023-02-21) SQLITE_DBCONFIG_DQS_DDL and SQLITE_DBCONFIG_DQS_DML are disabled by default in the CLI. Use the ".dbconfig" dot-command to reenable the legacy behavior if desired.