Add push and pull versions of vectors of known length

[aspiwack]

Is your feature request related to a problem? Please describe.

Vectors of known length (or whatever they will eventually be called #207 ) have a data applicative instance. Said instance is used, for instance, in the definition of deep-copy style instances for the Dupable type class (see e.g. the instance for lists).

The limitation of these instances is that when chaining, say, f <$> dupV <*> dupV <*> dupV, each operators allocates an array. In this case, there are three allocation, but we need only one.

It is wasteful

Describe the solution you'd like

We'd like to provide a push and pull array framework (and, presumably, destinations as well) for vectors of known length.

The pull array variant would have a data applicative instance.

A new dup-type method would be added to the Dupable type class, similar to dupV but for pull arrays. And dupV would receive a default implementation in terms of the pull-array dup. The applicative-style instances would be migrated to the pull-array dup

Describe alternatives you've considered

• We could remove dupV as a method from Dupable altogether. Though, when creating a basic type instance (say, for the Pool type, as an example of something which isn't Movable (Movable thing will have a natural pull-array implementation)), the pull-array dup would need to allocate an array anyway, so if dupV is derive, it would just copy this array which is a bit silly. So I think that we should keep dupV in.
  • Unless there is a meaningful implementation of a pull array from dup2, which there may be? Probably not with the current implementation of pull array, though, but maybe the problem is the implementation, not the concept.
• We could rely of array fusion instead. It's not really in the spirit of linear base, though. And it doesn't chain: if I have a dupV that calls another dupV, probably fusion could make both single allocation, but the latter dupV will probably still need to allocate (unless the proper inlining happens), but it shouldn't have to. Last, but not least: the calls to Unsafe.linear will block vector's fusion framework at least until the thorny question of multiplicity casts is solved. So it would probably be more work to build a fusion framework than to do the pull/push array story.

Additional context N/A