[Feature]: improve the "split" and "sequential" features

### Feature Request

I had a difficult time understanding the "split" and "sequential" features, even after reading the docs - I went on the Discord and got more of an explanation from [this video](https://www.youtube.com/watch?v=8aU3His4IdQ), and I understand now why this feature was confusing, but I'd like to make some suggestions.

First off, when you enable "split", the "max" input appears with a default value of 10 - this was my first source of confusion.

It turns out, this value is a hard limit - any input over 10 elements is simply discarded.

I understand this feature is there to "protect" users against accidentally blowing all their credits on massively parallelized workloads. 😅

But the need to actually truncate your input for real workloads (anything other than early testing) is probably extremely rare - so I don't think this setting makes sense as a default.

But I'm not really convinced this feature makes any sense at all. If your actual intention was to truncate your input for any reason, using the "slice" node would seem like a more natural, explicit, and self-explanatory choice here.

What might be useful, is to parallelize a workload, to save time when running larger workloads - for for this case, I would expect a feature that works more like a [promise pool](https://www.npmjs.com/package/p-limit), limiting the number of parallel tasks *without* truncating the input.

As for the "sequential" option, understanding how "split" and "max" works, things got even more confusing: sequential appear to mean it's *not* splitting - even though the "split" option needs to be enabled for "sequential" to even show up. In "sequential" mode, it's *not* parallelizing the workload, it's literally just truncating the input.

What I would suggest:

* Drop the terms "split", "max" and "sequential", as none of these are easy to understand.
* The first option could simply be named "repeat" - this would enable the node to process multiple inputs.
* When "Repeat" is enabled, additional options could show up:
* a "Concurrency" setting would specify the max number of tasks to run in parallel, using some sort of pool or queue - to avoid budget explosions, I would suggest a default of `1`.
* With concurrency > 1, I would suggest values should arrive at the output in the same order they were added. (at least by default - you might consider adding an option in the future to let values arrive at the output in undefined order, as quickly as possible.)

If you think the ability to truncate the input is very important, I would suggest an option labeled "Truncate", which would display a numeric input labeled "Limit", which might default to `10` as before.

For backwards compatibility, when loading an existing diagram:

* If "split" and "max" are set, enable "Repeat" with "concurrency" set to the old "max" value, and enable "Truncate" with "Limit" also set to the old "max" value.
* If "sequential" is set, disable "Repeat", and enable "Truncate" with the previous "max" value.

This should give you the same behavior as before, keeping things functionally backwards-compatible, while improving the functionality and semantics.

### Code of Conduct

- [X] I agree to follow this project's Code of Conduct

No files or tests are named. Start by tracing the existing split, max, and sequential settings and the diagram-loading compatibility path; done would require the requested naming, concurrency and truncation behavior, output ordering, and backward compatibility to be specified and covered.

Written by the indexing model from the issue text.