Minor: Allow Field::new and Field::new_with_dict to take existing String as well as &str

[alamb]

Which issue does this PR close?

N/A

Rationale for this change

Sometimes (e.g. apache/datafusion#4534) a caller already has an owned String but today Field requires &str which forces another clone

What changes are included in this PR?

Change Field::new() to take impl Into<String> so that anything that implements impl Into<String> , such as String, can be passed

Are there any user-facing changes?

The API is changed but is backwards compatible

[viirya]

Not sure if I understand the purpose clearly. Doesn't it work for now:

let s = String::from("c1");
Field::new(&s, DataType::Int64, false);

[tustvold]

Internally that will create a new memory allocation and copy the string data across, effectively this saves a Clone

[viirya]

Thanks for the explanation!

[viirya]

BTW, I think this represents an api-change?

[viirya]

Added the label. Feel free to remove it if you think it is not necessary.

[alamb]

BTW, I think this represents an api-change?

I agree it is technically an API change, I think it will be backwards compatible in the sense that any code that created Field::new() previously will continue to work. Normally I thought api-change label is applied to breaking changes, but it is ambiguous.

The backwards compatible story is consistent with the fact that no tests needed to be changed

[tustvold]

previously will continue to work

Technically this is still a breaking change, as it could now fail to infer the type of an expression where previously it could. However, in the past we haven't considered this sort of change "breaking".

[alamb]

Well let's leave the label on it then