Export to_datafusion_err from the util crate root

[kosiew]

Which issue does this PR close?

• Closes Minor annoyance with the util crate #1431.

Rationale for this change

Users currently cannot import to_datafusion_err directly from datafusion_python_util, even though the function is already public in errors.rs. This creates an inconsistency between the function’s visibility and how consumers expect to access it from the crate root.

This change fixes that mismatch by re-exporting to_datafusion_err from lib.rs, making the crate’s public API behave as expected and resolving the private item import error reported in the issue.

What changes are included in this PR?

This PR makes a small public API cleanup in the util crate:

• Re-exports to_datafusion_err from the crate root with pub use crate::errors::to_datafusion_err;
• Updates the internal use statement in lib.rs so the root re-export and internal imports are separated cleanly
• Adds a regression test in crates/util/tests/root_exports.rs to verify that to_datafusion_err can be imported from datafusion_python_util

Are these changes tested?

Yes.

This PR adds a regression test, exports_to_datafusion_err_from_crate_root, which imports to_datafusion_err from datafusion_python_util and verifies that the symbol is available from the crate root. This helps prevent future regressions in the crate’s public exports.

Are there any user-facing changes?

Yes.

to_datafusion_err is now importable directly from the datafusion_python_util crate root:

use datafusion_python_util::to_datafusion_err;

This is a small user-facing API improvement, but it is not a breaking change.

LLM-generated code disclosure

This PR includes code, comments generated with assistance from LLM. All LLM-generated content has been manually reviewed and tested.