Document dlclose restrictions for Go-based (cgo) drivers

[metegenez]

What feature or improvement would you like to see?

Following up on the discussion in #4206 (comment)

• Go-based drivers (Flight SQL, Snowflake): dlclose hangs or crashes because the Go runtime does not support clean unload (runtime: support dlclose with -buildmode=c-shared golang/go#11100). The Rust driver manager already works around this by skipping dlclose (fix(rust/driver_manager): don't dlclose drivers #3844, fix(csharp/src/Apache.Arrow.Adbc/C): Stop trying to unload dynamic libraries #3291), but this is not documented in the C API.
• C/C++ drivers (SQLite, PostgreSQL): presumably safe, but not documented either.
• Rust drivers: untested per maintainer.

Embedders integrating the C driver manager (e.g., StarRocks, DuckDB) currently have to discover this through the Rust manager's changelog or by debugging hangs at process shutdown.

Proposal: add a section to the C driver manager (maybe for JNI part as well) documentation covering:

1. dlclose must not be called on Go-based driver handles. Driver handles should stay resident until process exit.
2. Cleanup should go through the ADBC API only: AdbcStatementRelease -> AdbcConnectionRelease -> AdbcDatabaseRelease.
3. Multiple Go-based drivers can be dlopen-ed in the same process on Linux and ARM macOS, but not on Intel macOS (due to an unresolved Go runtime bug).

[CurtHagenlocher]

When I originally prototyped the C# implementation, I had support for loading an AOT-compiled C# driver through the native API (e.g. from Python). The code is still present in the repo, but I haven't found the time or motivation to productize it yet. But if I did, then a C#-built driver would have the same limitation of FreeLibrary/dlclose being broken. This makes me wonder whether we ought to have a mechanism for drivers to let the driver manager know whether or not they support unloading. A Go driver could report different things based on which platform it was running on.