All algorithms should be usable with generic containers

[antiguru]

Differential offers many algorithms that absorb input data in some form. Most (all?) are compatible with vector-based data, and some support generic containers, or specific instances of containers other than vectors. We'd like to support generic containers or make it possible to easily integrate new specific containers for all parts of Differential. Here's an overview where we stand:

• arrange_core: Can absorb all data for which we have a merge batcher.
• Merge batcher: Generic over input/output data, but sometimes lacks flexibility, and is complex.
  • The merge batcher should not name Input, but be generic over some variant of Push.
• Half-join: Requires Vec
• Collection: Type can have generic containers, names owned D/T/R, but not very usable for other containers than Vec.
  • Map only for Vec
  • map_in_place
  • flat_map
  • filter
  • explode
  • join_function
  • enter/leave
  • enter_at
  • delay
  • inspect
  • inspect_batch
  • assert_empty: needs consolidate
  • consolidate/consolidate_named: Work-around to build arrangement.
  • consolidate_stream: Uses ConsolidatingContainerBuilder
  • negate is aware of containers (trait operators::Negate), but generic parameters are in wrong order. See Introduce EnterTime, fix Negate #587
• ConsolidatingContainerBuilder
• Remove TimelyStack

There are a bunch of types that we don't use a lot, so the list is likely incomplete.

[frankmcsherry]

Some thoughts: one conclusion from recent columnar stuff is that it's really the container and its thoughts about reference types that drive a lot of the code. Additionally, the container is the thing that defines the layer, rather than the owned input type, and it seems its opinions go further than the type: also e.g. the order and layout, for effective merging/intersection/etc.

I think point being, imo it may be fine to only be some amount of generic: if half_join needs to take a container as input, it seems reasonable for it to say "it needs to be my container" rather than making it generic over other containers as well. Transforming the container is a thing we can do, but we can probably avoid needing to teach each operator how to do this, and instead could have a bump on the wire operator for moments where it turns out we want to fit together two unrelated containers.