Deprioritize the Vec container

[frankmcsherry]

This PR imagines deprioritizing the VecCollection type that is a stream around a Vec container.

Specifically, we group together the methods on VecCollection in their own mod vec, and migrate the vector specific parts of reduce.rs here. The Reduce (and others) traits that produce streams with vector containers are made inherent methods on VecCollection, and are not surfaced as traits.

There are trade-offs here:

1. On the one hand, it is now easier to use these methods because there are no extension traits to import.
2. On the other hand, it can be harder to go from an arrangement to "a stream of whatever, vec containers I guess".

I didn't go as far as doing the same thing with join.rs, as the output type there is inherently not an arrangement, and it's not as clear how to pilot the joining of arrangements to success without insisting on a container builder. Perhaps that's right, and the right thing to do, but also wanted to share this before going too deep.

[frankmcsherry]

To call out, this is an example where things are more tedious than before, as there isn't an easy way to get something that defaults to 1. any trace at all, and 2. vector output. This feels like an ergonomic nit we could fix, e.g. with some method on arrangements that are vec appropriate, so that type inference would drive it.