[C++] Rename "struct_field" kernel, or add new kernel for generic FieldRef selection in projections?

[jorisvandenbossche]

We have a "struct_field" kernel that was added to perform a FieldRef selection in compute / projection context (#11641).
Although it is called "struct_..", it can actually already handle a union type as well. And #14697 is expanding it further to also allow a FieldRef to select a list element.

So if the current "struct_field" kernel is evolving in a kernel to perform any kind if Field Reference lookup, should we rename it to something more generic like "select_field"?
(or add a separate kernel that does that, and keep "struct_field" specific to structs?)

cc @lidavidm @westonpace

[lidavidm]

Given the other discussion about FieldRef::Get, perhaps we should 1) move its functionality out of compute and 2) rename it? I'm fine with renaming

[westonpace]

This is transparent to the user correct? They just call ProjectNodeOptions({field("a.b.c")}) and don't know it is using struct_field under the hood?

In that case, I think renaming struct_field is fine. Though it is part of the public API so we should leave struct_field as an alias (potentially marked for deprecation if we can do that in a compute kernel).