fix: Avoid re-wrapping planning errors Err(DataFusionError::Plan) for use in plan_datafusion_err

[avkirilishin]

Which issue does this PR close?

Closes #13979.

Are these changes tested?

I added several new unit tests in sql_integrations, despite the fact that some cases are already covered in sqllogictest. It was also manually tested (removed the duplicated 'Error during planning'; no changes made to 'Error during planning: Execution error:' in the third case):

Before	After
> select version(1); Error during planning: Error during planning: Failed to coerce arguments to satisfy a call to version function: coercion from [Int64] to the signature Exact([]) failed. No function matches the given name and argument types 'version(Int64)'. You might need to add explicit type casts.	> select version(1); Error during planning: Failed to coerce arguments to satisfy a call to version function: coercion from [Int64] to the signature Exact([]) failed. No function matches the given name and argument types 'version(Int64)'. You might need to add explicit type casts.
> select rank(1) over(); Error during planning: Error during planning: The function expected zero argument but received 1 No function matches the given name and argument types 'rank(Int64)'. You might need to add explicit type casts.	> select rank(1) over(); Error during planning: The function expected zero argument but received 1 No function matches the given name and argument types 'rank(Int64)'. You might need to add explicit type casts.
> select max(1,2); Error during planning: Execution error: User-defined coercion failed with Execution("min/max was called with 2 arguments. It requires only 1.") No function matches the given name and argument types 'max(Int64, Int64)'. You might need to add explicit type casts.	> select max(1,2); Error during planning: Execution error: User-defined coercion failed with Execution("min/max was called with 2 arguments. It requires only 1.") No function matches the given name and argument types 'max(Int64, Int64)'. You might need to add explicit type casts.

Are there any user-facing changes?

Although the output of some errors will change (improve), changes in the documentation are probably not necessary.

[alamb]

Thanks @avkirilishin -- this looks like a very nice improvement to me to avoid double wrapping the errors

[alamb]

Thanks again @avkirilishin

[niebayes]

Great work!