Better From DatafusionError trait for PyErr

### Is your feature request related to a problem or challenge?

The Python errors are badly mangled in datafusion-python, see https://github.com/apache/datafusion-python/issues/1226.

Basically, when going from Python -> Rust -> Python, the original Python stack trace is lost. We could use DataFusionError::External to store the original PyErr, as demonstrated in this [POC](https://github.com/mesejo/arrow-datafusion-python/tree/fix/unmangle-errors), but I think the right place for this transformation is the From trait.

### Describe the solution you'd like

A solution would be to change the [From trait](https://github.com/apache/datafusion/blob/main/datafusion/common/src/pyarrow.rs#L29) defined in pyarrow.rs to

```rust
use pyo3::exceptions::{PyException, PyNotImplementedError};
use pyo3::prelude::PyErr;
use pyo3::types::{PyAnyMethods, PyList};
use pyo3::{Bound, FromPyObject, IntoPyObject, PyAny, PyObject, PyResult, Python};

use crate::{DataFusionError, ScalarValue};

impl From for PyErr {
fn from(err: DataFusionError) -> PyErr {

match err {
DataFusionError::External(boxed) => match boxed.downcast::() {
Ok(py_err) => *py_err,
Err(original_boxed) => PyException::new_err(original_boxed.to_string()),
},
DataFusionError::NotImplemented(message) => PyNotImplementedError::new_err(message),
_ => PyException::new_err(err.to_string()),
}
}
}
```

### Describe alternatives you've considered

_No response_

### Additional context

_No response_

Start in datafusion/common/src/pyarrow.rs and inspect the existing From for PyErr implementation. Compare its behavior with the linked proof of concept, then verify that External errors preserve the original PyErr while NotImplemented errors retain their specialized exception; done means the relevant existing checks pass and Python stack traces are no longer mangled.

Written by the indexing model from the issue text.