perf: use a set instead of Vec<_> to optimize large subscriber sets (see #4138)

[gbj]

@bicarlsen At your convenience, could you please test this against the performance issue discussed in #4138?

The tradeoffs here are probably:

1. marginal performance cost for signals with one or a few subscribers, and for effects/memos with one or a few sources (Vec<_> lookup being cheaper than hashmap lookup for very small cases) -- but this is not likely to be measurable because it's from "very fast" to "also very fast"
2. marginal, constant increase in binary size: this appears to be about 6-7kb in release mode. It's not generic and is used everywhere, so that should be a constant one-time cost, i.e., a simple counter goes up from 69kb to 76kb, but a more complex todomvc goes from 277 to 283kb. given real application sizes and compression this is really a non-issue beside the (imaginary) bragging rights of how small the baseline can be made
3. significant performance increase for large dependency graphs (hopefully!)

Let me know if it helps with your case and we can swap it out. I don't think the downsides are a good argument against it.

[bicarlsen]

Nice! I tested on my app (specifically on the workspace_graph and workspace_db crates) and got quite a nice speed up.

Timings for SubscriberSet::subscribe (ms)

--	graph	db
Vec (current)	123.3	363.4
IndexSet (this PR)	106.0	271.3
$\Delta$	14%	25%

where $\Delta$ indicates the change in time spent in SubscriberSet::subscribe. i.e. (Vec - IndexSet) / Vec.

Seems like using IndexSet gives quite a significant performance boost on this specific benchmark :).

Grain of salt
I'm not a performance expert, so it's really hard for me to say if/how this affected other aspects of the app. e.g. Were other methods of SubscriberSet effected negatively?

Here are the profiles I took.

[gbj]

Thanks for verifying that it had a benefit!