Remove from string column

[ishanema03]

Which issue does this PR close?

• Closes Remove From<String> for Column #17375

Rationale for this change

As mentioned in the issue, the From trait implementations for Column were misleading - they invoked Column::from_qualified_name() which parses and lower-cases field names, making conversions like field.name().into() behave unexpectedly. Requiring explicit calls to Column::from_qualified_name() makes the behavior clear and prevents misuse.

What changes are included in this PR?

• Removed From, From<&str>, and From<&String> trait implementations for Column
• Updated col() and unnest() functions to accept strings directly
• Replaced all .into() usages with explicit Column::from_qualified_name() calls across the codebase

Are these changes tested?

Yes, all existing tests have been updated and pass with the new API.

Are there any user-facing changes?

Yes, this is a breaking API change:

• Users must now call Column::from_qualified_name() explicitly instead of using .into()
• The helper functions col() and unnest() still accept strings directly

[alamb]

Thank you @ishanema03

I think this is a non trivial breaking API (as you can see by the number of API changes)

I understand the rationale for trying to make the API easier to use, but I think we need to balance that against the need to avoid breaking downstream users who are already using the APIs

Can someone help me understand if there is some particular bug this is solving?

I think some of the nuance on API change guidelines isn't well documented, so I'll make a PR to update it https://datafusion.apache.org/contributor-guide/api-health.html

[alamb]

I wrote up some thoughts here

• Document guidance on how to evaluate breaking API changes #20584