Rationalize type of (key, val) to row mapping

[frankmcsherry]

We use a BTreeMap<usize, usize> for the "permutation" from concatenated [key, val] columns, when it appears it can always be a Vec<usize>: each output column must identify an input column. This also hints that this isn't really a permutation as much as a projection. More generally both of these could be Vec<MirScalarExpr> if we ever plan to be so bold (and perhaps this is an opportunity to abstract the specifics away, so that everyone's signatures don't change in the future). For example, various permute functions could/should be pre-mfp where you hand over perhaps a Vec<MirScalarExpr> that could be column references, or more general expressions. E.g. if we form a key using a cast, we cannot represent the operation that just un-casts it (in some cases) and that would be good enough vs keeping the un-cast column around as a value.

Motivation

Tips for reviewer

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• This PR includes the following user-facing behavior changes:

[antiguru]

Can we change permute to accept a &[usize] instead? If I'm reading this correctly, all uses are of the form permute(permute.into_iter().enumerate().collect(), ...), unless there are some outside of this change that I can't see here!