Layout extension trait

[frankmcsherry]

The intent here is to provide a LayoutExt extension trait for types that have a Layout member, to provide them with type aliases and methods on them, e.g. "owned key", "borrowed key", "borrowed to owned function".

This seems to work, but .. there are some mysterious edits needed to unlock the type inference. On that stood out was changing a Tr: Trace + TraceReader< ... > bound into a Tr: Trace< ...> bound. No idea why Rust needed the constraints in that trait, where trait Trace : TraceReader. Perhaps they need to be in the trait at the top of the stack rather than halfway through; I couldn't say.

Hesitant to merge without a better understanding of what is going on, and how much maintenance peril we are in. It's all a bit silly because all we are trying to say is "everyone has the same L: Layout", and .. perhaps the right thing to do is just to add it as a trait argument, e.g. Trace<L>, Batch<L>, Cursor<L>, and life could be better. Though at the same time it really is an associated type: each trait implementations has a single layout in mind.

[frankmcsherry]

I'm tempted to say that the complexity (and anxiety) about the layout extension trait might justify just eating the complexity of copy/pasting its contents into each of Cursor, BatchReader, and TraceReader, and having the enormous impl blocks. But at least some confidence about how the trait and type resolution works. Pondering now.

[frankmcsherry]

I'm ok merging this, and promise that I'll help undo it if it turns out to be the wrong architecture. But I'm pretty confident that I understand it better now, and that the worst-case scenario is that we inline the LayoutExt types and methods in a few traits, and have a bunch of boilerplate implementations.