RF cum_concat_step simplify and other RF things

[albertz]

(This is just here to at least run the test once before I merge it into main.)

(The other commits accidentally went into here, but it cannot hurt. Let's just not squash them together but rebase then.)

[NeoLegends]

What about the other backends? It seems strange to me that only one backend can pad w/ non-scalar values. If we only implement this for torch I'd rather adjust the RF cum_conat_step impl to not rely on rf.pad but a more general operation that works across all backends, no?.

[albertz]

What about the other backends? It seems strange to me that only one backend can pad w/ non-scalar values. If we only implement this for torch I'd rather adjust the RF cum_conat_step impl to not rely on rf.pad but a more general operation that works across all backends, no?.

There is not really any other backend currently which fully works and is actively used, so I don't think this has such a high priority now.

[NeoLegends]

But is it much work to change the impl to be generic by default? If we ever add more tier 1 backends that is one less thing to worry about?

[albertz]

I don't exactly understand? Via this PR, rf.cum_concat_step becomes generic, so this PR here fixes this?

[NeoLegends]

I mean wrt. rf.pad of non-scalar values.

[albertz]

But I still don't understand? rf.pad never supported non-scalar values? Now it does for the PT backend. rf.pad is a backend function. There is no way to have this more generic?