refactor(duckdb): use .sql instead of .execute in performance-senitive locations

[jcrist]

In #6875 we switched to using con.sql(sql) instead of con.execute(sql) when retrieving an arrow table of results. The former is more efficient than the latter since the .sql api lets the query planner take advantage of the known output type, possibly resulting in a more efficient execution.

In the the-epic-split refactor this optimization was dropped (note - it seems less necessary since duckdb 0.9.0, although they say a performance difference is still expected). We add the optimization back here, and apply it to all locations where we return in-memory data.

We choose not to use duckdb_con.sql instead of duckdb_con.execute in the public-facing raw_sql api, since:

• The returned object isn't strictly compatible with the dbapi API
• In the case of operations that don't return results (e.g. DDL), con.sql returns None

Fixes #8631.

[jcrist]

Oh joy - segfaults on CI, but I can't reproduce them locally: https://github.com/ibis-project/ibis/actions/runs/8302276853/job/22724239870?pr=8669 👀 👀.

Debugging on CI it is then.

[cpcloud]

It's geospatial-related from duckdb/duckdb-spatial#236

https://github.com/ibis-project/ibis/actions/runs/8302276853/job/22724239870?pr=8669#step:15:125

[cpcloud]

LGTM, thanks!