Simplify duplicate detection in IdOrdMap::insert_unique_impl and IdHashMap::insert_unique_impl

[izuzak]

Hello 👋 I found a reminder in my notes for something I mentioned in passing in a previous PR:

Unrelated to this, the usage of BTreeSet for checking duplicates in IdOrdMap::insert_unique_impl and IdHashMap::insert_unique_impl also caught my eye. I think using BTreeSet here might not be necessary since the duplicate check can find at most one conflicting item. So, an Option<ItemIndex> or a direct early return might be enough. However, using BTreeSet does make the code more similar to the implementations in BiHashMap and TriHashMap, so overall it's a bit more consistent.

So, here's a small PR which replaces using BTreeSet<ItemIndex> for the duplicate check with Option<ItemIndex>. The benefits of doing this are small, but still wanted to offer it as a PR for consideration:

• it makes the code reflect the constraint a bit more directly (= an insertion into IdOrdMap and IdHashMap can conflict with at most one existing item), and
• it's a small performance improvement for the path when a duplicate is found. On that path, we'll now avoid the B-tree node allocation that happens when an insertion is made into the BTreeSet and also avoid the iteration logic for getting to the single duplicate. Creating an empty BTreeSet does not allocate, so the no-duplicates-found path (when nothing is inserted into the BTreeSet) doesn't benefit from this. Overall, this should be a small and rare performance improvement if we assume that most insertions into IdOrdMap and IdHashMap aren't duplicates.

[izuzak]

I noticed one of the linter checks complaining:

It runs just generate-readmes and then git diff --exit-code to verify that the generated README is up-to-date. And it says that the README is not up-to-date. I don't think this PR itself is the cause for the failing check, but rather that a new version of cargo-sync-rdme was released recently which changed the generated formatting. And because the CI workflow doesn't pin the version of cargo-sync-rdme it uses -- the README on main and what the CI check generates can get out of sync even without a PR.

I've re-generated the README and pushed the changes, and the linter is happy now. ✌️

[sunshowers]

I noticed one of the linter checks complaining:

It [runs `just generate-readmes` and then `git diff --exit-code`](https://github.com/oxidecomputer/iddqd/blob/9ece0e9b4379ab34ab6aee44bd45e91ca59f15f7/.github/workflows/ci.yml#L41-L44) to verify that the generated README is up-to-date. And it says that the README is not up-to-date. I don't think this PR itself is the cause for the failing check, but rather that [a new version of `cargo-sync-rdme` was released recently](https://github.com/gifnksm/cargo-sync-rdme/releases/tag/v0.7.0) which changed the generated formatting. And because the CI workflow doesn't pin the version of `cargo-sync-rdme` it uses -- the README on main and what the CI check generates can get out of sync even without a PR.

I've re-generated the README and pushed the changes, and the linter is happy now. ✌️

Thanks -- taking care of that in #309.

[sunshowers]

Thanks! Simplified this a bit further.