Add splitByElement() to Gherkin step definitions for nested collection parsing

[spmallette]

This PR completes #3216 which was for Java only but implements it across all the language variants. cc/ @yunlingTao

VOTE +1

[yunlingTao]

I think this is everything needed. Closed #3216.

[xiazcy]

VOTE +1

[kenhuuu]

There are only tests here for nested list, but this PR also changes set. Should add test for set as well as test for extra-depth in nesting.

[kenhuuu]

Consider a CHANGELOG entry? Though I think it might be small enough that it doesn't matter.

[Cole-Greer]

Overall I think this change looks good and I'll give it a VOTE +1 as a standalone inclusion.

I do want to point out that even with this change, nested collections in feature tests is sketchy and only works in specific cases. For example the following case looks reasonable, but does not work.

Given the modern graph
And using the parameter xx1 defined as "l[m[{\"name\":\"marko\"}]]"
And the traversal of
  """
  g.inject(xx1).unfold().select("name")
  """
When iterated to list
Then the result should be unordered
  | result |
  | marko |

The primary issue with this example is that the m\[(.*)\] matcher triggers before the l\[(.*)\] matcher, so it tries to parse {\"name\":\"marko\"}] as a map (note the trailing ] as it used closing bracket from the list to terminate the map).

In general mixed collection type nesting does not work and it's not a small change to fix it.

My view on feature test infrastructure is typically that I don't want complexity without necessity. I'm happy to leave these limitations if we don't intend to write tests that require mixed-type nests.