Create `CopyOptions` for controlling copy behavior

[alamb]

Is your feature request related to a problem or challenge?

This summarizes a discussion @devinjdangelo and I had here: #7283 (comment)

Basically the API for building a COPY statement is likely to get unwieldy relatively soon because of all the potential potential options:

https://github.com/apache/arrow-datafusion/blob/f2c0100a5a10bf3ea166a1a590d94b8c9b6cf673/datafusion/expr/src/logical_plan/builder.rs#L237-L243

Making a config struct would not only allow additional options to be easily added without an API change, it would also provide a natural location to document the options and what they meant

Here is an example of such a struct in the DataFrame API:

https://github.com/apache/arrow-datafusion/blob/f2c0100a5a10bf3ea166a1a590d94b8c9b6cf673/datafusion/core/src/dataframe.rs#L58-L63

And use

https://github.com/apache/arrow-datafusion/blob/f2c0100a5a10bf3ea166a1a590d94b8c9b6cf673/datafusion/core/src/dataframe.rs#L978-L982

Describe the solution you'd like

I propose a CopyOptions struct such as the following and changing the LogicalPlanBuilder::copy to take the struct:

CopyOptions {
  output_url: String,
  file_format: OutputFileFormat, 
  per_thread_output: bool,
  format_specific_options: FormatOptions
}
enum FormatOptions {
  Parquet(ParquetWriteOptions), 
...
};

Along with It might make sense to implement a CopyOptions struct with `CopyOptions::from(Vec<String,String>). :

impl From<Vec<String,String>> for CopyOptions {
...
}

Then, for the DataFrame::write_* API the user could construct CopyOptions directly rather than passing a Vec<String,String> as hey do today which is an awkward interface in comparison for use directly from rust code.).

Describe alternatives you've considered

No response

Additional context

No response