Reduce `ListIter` magic?

Nobody has claimed this yet.

Hi! I'm using a custom container to store app data: [slotmap](https://crates.io/crates/slotmap), because I need to reference some nodes by id. The slotmap contains several objects, and also I need access to referenced shared state. I implemented `ListIter` for the slotmap. But there were other challenges, as the shared state did not work yet:

I had a look at the `list.rs` example and boy! did it take long until I got it. I didn't understand how a tuple of two lists would suddenly be accessed element by element, of the second list in the tuple. I had to check all the implementations of `ListIter` with my IDE in order to understand that `ListIter` is implemented for `(S, Vec)`. I open this Issue in hope that we can reduce the magic in this part:
```rust
// S == shared data type
impl ListIter<(S, T)> for (S, Arc>) {
```

What took me so long was that this is implemented for `Vec` only, and not any type of collection. My first Idea was to `impl ListIter for (S, impl ListIter)`.

But maybe it would be easier to understand when we use a named type instead of a tuple type, like `ListDataStuff { shared_state: S, list_data: L }`. Or maybe some kind of method pair, like `list(list)` + `list_with_state(state, list)`?

I'd like to contribute the code for this.

Start with the list.rs example and inspect the ListIter implementations, especially the impl for (S, Arc>), to understand how shared state and list data are exposed. The issue does not select an API design; done would require an agreed change that makes this usage less magical and a corresponding contribution.

Written by the indexing model from the issue text.