Fix key terminology around various Index structs

[ggevay]

We have decided some time ago that

• "keys" should mean multiple (composite) keys, e.g. a Vec<Vec<MirScalarExpr>>;
• "key" should mean one (composite) key, e.g., a Vec<MirScalarExpr>;
• "key column", "key part", "key field", "key component" or simply "k" (which Frank uses, and is common in the optimizer) should mean one column of a composite key, e.g., a MirScalarExpr.

discussion:
https://materializeinc.slack.com/archives/C02PPB50ZHS/p1676473154162599

Motivation

• This PR refactors existing code.

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).
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

[aljoscha]

I don't really have an opinion on these, and someone closer to compute or the optimizer should review. I can give a blanket stamp if that's what's needed. 😅

[ggevay]

Ok, thanks, I'll wait for someone closer to compute or the optimizer.