Suggest removing some group.into { } overloads to simplify the primary use case

[koperagen]

What mostly concerns me here is that in order to create a simple grouping, which i believe is a main usage of this function, you have many options:

Both function have a replacement: move { }.under { }

[Jolanrensen]

I'd keep the first (group into string). Since move.into is designed to generate a new group with a new name, you might want to name a new group based on some information from the source, like: df.group { ... }.into { "newColumnName_${it.type}" }. This is also done in the examples.

The second (group into column) is indeed exactly the same as move {}.under {} and deviates a bit from the rest of group.into in that it asks the user to provide an existing column, not a new name. Maybe we can deprecate it in the future and keep the deprecation around a while so people are pointed to move {}.under {} when they use it.
(though, a valid use-case would still be df.group { ... }.into { "newGroup"["newColumnName_${it.type}"] }, which points to a new column by path and is thus different in intention than move.under... damn...)

[zaleslaw]

@koperagen how we could emulate with move { }.under { } the case, desribed by @Jolanrensen **"new group based on some information from the source, like: df.group { ... }.into { "newColumnName${it.type}" }."**_

I agree, that this is a case, if it's possible and could be replaced in examples, I am totally fine with removal