Refactor libodbc bindings

[georgestagg]

This PR refactors how we connect to ODBC databases using libodbc. It removes the dependency on odbc-api, instead loading the dynamic library at runtime using libloading and managing the FFI ourselves.

The odic-api crate requires us to dynamically link with the library at build time. On Windows this is fine because it's shipped with Windows, but it has the following consequences for Linux/macOS:

• The libodbc.dylib/.so library needs to be available at startup, even if you are not doing ODBC connections.
• So, we must ship it with the binaries. It is unreasonable to ask users to install unixodbc etc. when they are not even using it.
• So, we must change the dynamic library path to be relative to the installed binary, using RPATH and other trickery.

We did this in v0.3.0+, and it turns out to be very fragile:

• Once installed, ggsql-jupyter cannot be moved without also moving the dynamic libraries to match. This breaks the Jupyter installation process that copies ggsql-jupyter into place.
• The libodbc.so dynamic library bundled with the "manylinux" release may not work on other Linux distributions (e.g. workbench).

By switching to libloading and handling the ODBC FFI ourselves, the library is loaded at runtime on demand. That is, it's only pulled in if a user is trying to use an odbc:// connection. In that case, it is highly likely the required libraries are already installed on the machine at the system level. If not, we show an error asking the user to install unixodbc.

For everyone else, the library isn't loaded at all. This simplifies things massively. We don't have to worry about building dylibs in GHA release CI, we don't have to set RPATHs or use other linker tricks, the binary works as expected if it is moved or linked somewhere else, and we don't have to worry about cross-Linux compatibility.

These changes should fix #416 and #417.

[georgestagg]

Converting to draft until I can test some more next week...