`"group1" / "group2" / "column"` column path creation notation

Related to https://github.com/Kotlin/dataframe/issues/1684

In DataFrame, we currently have a shortcut for creating column paths inside the columns selection DSL:

```kt
df.select { "group1"["group2"]["col"] }
```
and with type:

```kt
df.select { "group1"["group2"]["col"]() }
```

We discussed an alternative notation akin to the `myPath / Path("subFolder")` shortcut in the [standard library](https://kotlinlang.org/api/core/kotlin-stdlib/kotlin.io.path/div.html).

Props to @koperagen for finding it :)

Adding this notation would make the API look like:

```kt
df.select { "group1" / "group2" / "col" }
```
and with type:

```kt
df.select { ("group1" / "group2" / "col")() }
```

Why to consider this alternative, pros:
* Stdlib has it for paths
* "/" Is often denoted in paths; we even print it when we refer to a nested column in errors :)
* It's one less character than "[]" (but adding two more for typed versions)
* It's more readable
* It makes all parts of the path appear equally important
* It cannot be confused like `"a"["b", "c"]` and `"a"["b"]["c"]` can. `"a" / "b", "c"` is simply impossible
* It can be mixed with column extensions if we want to: `a.b / "c"` / `(a.b / "c")()`

Why not consider it and the pros of our existing method:
* We already use ` "group1"["group2"]["col"]`
* `"a"["b"]["c"]` could be seen as two "getting" operations like `datarow["b"]["c"]`, similar to maps
* It's easier to add types to: `"a"["b"]["c"]()` compared to `("a"/"b"/"c")()`
* It can be mixed with column extensions: `a.b["c"]` / `a.b["c"]()`, which is a bit more intuitive, as it's just a `get` call.

Of course we still have `pathOf("group1", "group2", "group3")` which also works outside this DSL and is not going anywhere.

Feel free to leave ideas, examples, thoughts or any other comments below.

Start by reviewing the existing column-selection DSL entry points, including select and pathOf, and compare the current bracket notation with the proposed slash notation. Read related issue 1684 and the discussion here to determine whether the API direction is settled; done would require an agreed notation and an implementation scope.

Written by the indexing model from the issue text.