with_flatten: make the layer input/output types symmetric

[danieldk]

The idea of the with_flatten layer is that it flattens a nested sequence, passes it to the wrapped layer, and then unflattens the output of the wrapped layer.

However, the layer was asymmetric in that it passes a list to the wrapped layer, but expects back an XP array. This breaks composition with other Thinc layers, such as with_array.

This change makes with_flatten symmetric, in that the inputs/outputs of the with_flatten and the wrapped layer are symmetric.

It seems that this layer is not used in Thinc or spaCy, so maybe it never worked correctly? At any rate, I needed to flatten a nested list in distillation with with_flatten(with_array(...)) in distillation and found that it doesn't actually work.

[kadarakos]

Maybe its me, but since with_flatten is in a deep learning library my initial assumption was that it will call xp.flatten on an ArrayXd making it Array1d and it will reshape it back. Should it dynamically either flatten a list or a tensor? Should it be able to flatten any nesting level with lists just like any order tensor in xp.flatten? Or we just have it like this and add it into the documentation that this is flattening lists of lists (one level only)? Or is it just me who made the assumption? Don't want to derail the PR just mentioning that flatten for me invoked something different.

[danieldk]

Maybe its me, but since with_flatten is in a deep learning library my initial assumption was that it will call xp.flatten on an ArrayXd making it Array1d and it will reshape it back. Should it dynamically either flatten a list or a tensor? Should it be able to flatten any nesting level with lists just like any order tensor in xp.flatten? Or we just have it like this and add it into the documentation that this is flattening lists of lists (one level only)? Or is it just me who made the assumption? Don't want to derail the PR just mentioning that flatten for me invoked something different.

These are good questions, and I agree that our naming it not really in line with other deep learning libraries, though it is kinda the normal FP definition.

At any rate, this PR is just for fixing the existing implementation which just flattens one level of lists. If we want something more advanced, it should probably have a different name to avoid confusion (and a separate PR).