impl FromIterator, silence some of clippy::pedantic

[mmirate]

This allows users to concisely build an entire MultiIndexMap from an iterator (though it would be interesting to figure out a more optimized implementation too). While I was at it, I also added an IntoIterator impl for references to the map (cf https://rust-lang.github.io/rust-clippy/stable/index.html#iter_without_into_iter) and silenced a number of other clippy::pedantic warnings in the crates themselves.

[lun3x]

nit: stray commented out line here

[lun3x]

Thanks for the change! I have bumped the crate MSRV to 1.65 in master to allow the use of let ... else in index_attributes.rs.
Would be good to add a test to check this new FromIterator behaviour. Particularly the behaviour on duplicate values. I think this is probably the cleanest way to implement it, I think it's difficult to match the HashMap and BTreeMap last-insert wins.

[mmirate]

Aye, the current gamut of operations is "close but no cigar" - the error gives back a clone of the offending element, but there's no "remove exactly this element" method conditionally generated for MultiIndexMaps with at least one unique index.

I've rebased this to collapse down into a single commit that fast-forwards from master; now includes a unit test of the conflict resolution direction, removal of that stray commented-out line, a few more let-elses that I somehow missed the first time around, and a doc-comment on the generated FromIterator impl which mentions the conflict resolution direction.

[mmirate]

(Even for MultiIndexMaps without at least one unique index, I suppose it might still be interesting to have methods who return, instead of an ordinary & reference, some kind of smart pointer who derefs to the element but also has an inherent method which consumes the smartpointer and deletes the pointee from the MultiIndexMap.)

[lun3x]

(Even for MultiIndexMaps without at least one unique index, I suppose it might still be interesting to have methods who return, instead of an ordinary & reference, some kind of smart pointer who derefs to the element but also has an inherent method which consumes the smartpointer and deletes the pointee from the MultiIndexMap.)

Could be interesting, although you need to think about what happens if the map itself is dropped while a smart pointer is alive. The smart pointers could hold weak references, but that potentially makes the api not super clean, or they could hold strong references but then the values in the backing store need to be kept alive past the lifetime of the map.