Support an additional (optional) key in iddqd::IdOrdMap (“BiOrdMap”)

I love this crate, thank you for all the work!

Quick notice: I’m happy to help drive this feature, but my bandwidth is very limited for the next 6 weeks.

Background
IdOrdMap<K,V> today maintains exactly one sorted key. I need one primary index (sorted) and a secondary key for fast lookup, without being forced to rebuild maps or sort on the fly.

I began this on Reddit but it’s complex enough to merit an in-repo API discussion.

Options

1. Only primary sorted + secondary lookup
   • Simple, but if you later need to sort by the second key, you’re back to ad-hoc sorting or a separate map.
2. Two always-sorted keys
   • Two B-trees under the hood; higher memory & insertion/removal cost.
3. Primary sorted + optional sorted
   • Zero-cost if you don’t invoke the second sort.
   • API is trickier: needs either builders/constructors or trait-gated impls.

API Questions
• Should one hard-code a .with_secondary_index() constructor, or infer “sortable” from K: Ord + Clone?
• Does one expose separate .iter_by_primary()/.iter_by_secondary() methods, or a unified .iter(Index)?
• Is it better to have separate BiOrdMap vs. a single generic type with optional indices?

Initial Proposal
Introduce a BiOrdMap<K1, K2, V> that always provides:
• Primary sorted index on K1
• Secondary unsorted lookup by K2

This stays close to the existing API, provides a playground to refine constructors, method names, and performance trade-offs, and lays groundwork for an optional‐sort variant later.

Feedback and real-world use cases welcome!

Start by reading the existing IdOrdMap API and its current indexing behavior. Review the proposed BiOrdMap design and the constructor, index, and iteration questions, then establish the intended API and performance trade-offs before implementation. Done means the design is agreed and the new map behavior is covered by appropriate tests.