Many rules store a Vec<String> in their configs for things like ignore lists or JSX tags that should be checked. They are created once (in from_configuration) and mostly used for Vec::contains. There are a few problems with this:

1. Strings are always heap-allocated. We should inline when possible, using CompactStr.
2. Vec::contains is O(n), and is usually used in a hot path.
3. Vec::contains requires an &T, meaning there are many cases when rules have an &str and need to allocate a new String just to pass it to contains. This is highly wasteful.
4. Many rules have duplicate logic for parsing a Vec<String> from a Value.

This PR adds Set<T>, which seeks to make this use case more performant. It's very simple ordered set of unique items backed by a Vec. Read the doc comments over the struct definition for a more in-depth rationale.

Improvements

1. Set<T> supports O(log(n)) containment checks at the cost of O(nlog(n)) initialization. This is fine since we create it once and read from it many times.
2. Set<T> where T: AsRef<str>> supports a contains_str method that is identical to contains but does not force consumers to allocate new strings
3. Set<CompactStr> implements TryFrom<Value>, which DRYs up rule config parsing. This trait is intentionally not implemented for Set<String> to nudge rules towards using CompactStr.

Following PRs will modify existing rules to use Set<CompactStr> over Vec<String>. Since most of these cases are within Jest and VITest rules, I don't expect improvements to appear on benchmarks (rules are skipped when non-applicable, and we have no benchmarks for Jest specs).