libduckdb-sys: expose DEP_DUCKDB_INCLUDE for downstream C/C++ shims

[frhack]

What

Add links = "duckdb" to libduckdb-sys's manifest and emit cargo:include=<path> from each backend so downstream crates that compile their own C/C++ code can read the resolved DuckDB include directory from DEP_DUCKDB_INCLUDE in their own build scripts.

Why

Crates that ship native extension code (e.g. an OptimizerExtension shim that #include "duckdb.hpp") need access to libduckdb-sys's DuckDB headers at their own build time.

Today they have to either:

• Glob target/<profile>/build/libduckdb-sys-<hash>/out/duckdb/src/include from their build.rs, or
• Vendor a copy of the DuckDB headers into their own crate.

Both are fragile: the glob breaks across cargo versions and is awkward in cross-builds; vendoring drifts from the bundled DuckDB ABI on every libduckdb-sys upgrade.

The standard Cargo mechanism for this is the links directive plus cargo:KEY=VALUE metadata. With this PR, downstream code can simply:

// downstream build.rs
fn main() {
    let inc = std::env::var("DEP_DUCKDB_INCLUDE").unwrap();
    cc::Build::new()
        .cpp(true)
        .file("cpp/extension_shim.cpp")
        .include(&inc)
        .compile("my_extension_shim");
}

This unblocks downstream crates from registering things like duckdb::OptimizerExtension from their own native code without resorting to the C API (which the issue at duckdb/duckdb#19093 is still working out).

Changes

• crates/libduckdb-sys/Cargo.toml: add links = "duckdb" so build-script metadata flows to downstream DEP_DUCKDB_* env vars.
• crates/libduckdb-sys/build_bundled_cc.rs: emit cargo:include=<OUT_DIR>/duckdb/src/include.
• crates/libduckdb-sys/build_bundled_cmake.rs: emit cargo:include=<duckdb-sources>/src/include.
• crates/libduckdb-sys/build.rs (the build_linked path): emit cargo:include=... derived from the resolved HeaderLocation — DUCKDB_INCLUDE_DIR, DUCKDB_LIB_DIR, vcpkg, pkg-config, or download dir.

Wrapper-only mode (system DuckDB found via pkg-config without an explicit include path) intentionally skips the emission — there's no single directory to publish; the system header is already on the default search path, and downstream shims fall through to the same default include resolution.

Behaviour change

None for existing Rust consumers — the only public-surface change is a new links directive, which doesn't affect compilation of crates that don't run their own build.rs against duckdb headers.

Validation

The companion downstream project that motivated this PR (dbfy — embedded SQL federation engine, github.com/frhack/dbfy) ships an OptimizerExtension shim in bundled mode (--features duckdb) that needs these headers. Its build.rs currently uses the target-tree glob hack as a documented workaround; once this PR is in a release, the shim can switch to the clean DEP_DUCKDB_INCLUDE path.

Happy to add a small test or example exercising the metadata if useful.

[mlafeldt]

Thanks!

Happy to merge this once you address the mentioned path bug and format your code with cargo fmt.

[mlafeldt]

This is currently relative but should be absolute so downstream build scripts can actually use it.

Suggested change

	let include_path = source_dir.join("src/include");
	let include_path = source_dir.join("src/include").canonicalize().unwrap();