perf: Use a Vec for CycleHeads

[Veykril]

The number of cycle participants is generally low so a hashset likely has more overhead compared to a simple vec for such small numbers of elements.

[netlify]

✅ Deploy Preview for salsa-rs canceled.

Name	Link
🔨 Latest commit	5b718d7
🔍 Latest deploy log	https://app.netlify.com/sites/salsa-rs/deploys/67d5bab60dbe3e00089c1d8c

[codspeed-hq]

CodSpeed Performance Report

Merging #760 will improve performances by 5.54%

_{Comparing Veykril:veykril/push-myoqmkxmwwrm (5b718d7) with master (1bbf4c2)}

Summary

⚡ 4 improvements
✅ 8 untouched benchmarks

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
⚡	amortized[Input]	3.6 µs	3.5 µs	+5.12%
⚡	amortized[InternedInput]	3.5 µs	3.3 µs	+5.3%
⚡	amortized[SupertypeInput]	4.3 µs	4.1 µs	+5.03%
⚡	converge_diverge	157.7 µs	149.4 µs	+5.54%

[carljm]

Looks great, thank you!

[carljm]

I don't know if you consider this an improvement, but we can eliminate CycleHeadsIter and implement IntoIterator for &'a CycleHeads like so:

impl<'a> std::iter::IntoIterator for &'a CycleHeads {
    type Item = DatabaseKeyIndex;
    type IntoIter = std::iter::Copied<std::slice::Iter<'a, DatabaseKeyIndex>>;

    fn into_iter(self) -> Self::IntoIter {
        self.0
            .as_ref()
            .map(|heads| heads.iter())
            .unwrap_or_default()
            .copied()
    }
}

[Veykril]

This causes new[InternedInput] to regress due to a report_tracked_read becoming more expensive, so something optimizes differently there 😕 Will drop our Extend impl as we can optimize around knowing the concrete iterator anyways.