chore: 🤖 make parking_lot dependency optional

[IWANABETHATGUY]

Summary

parking_lot is not always the best choice after rust stable 1.62 https://blog.rust-lang.org/2022/06/30/Rust-1.62.0.html#thinner-faster-mutexes-on-linux

1. Make parking_lot an optional dependency
2. Adding a new feature parking_lot_support to let user enable the optional dependency parking_lot
3. Adding the feature parking_lot_support to the default_features list to avoid breaking changes.

[IWANABETHATGUY]

Here is the benchmark for current std::sync::Mutex rust-lang/rust#95035 (comment), It is 10 times faster than parking_lot::Mutex when the extreme contention scenario, although not all platforms have been migrated to Mutex with futex based ones (e.g. MacOs ), more details you could refer to rust-lang/rust#93740

[bors-servo]

☔ The latest upstream changes (presumably #268) made this pull request unmergeable. Please resolve the merge conflicts.

[SimonSapin]

Closing as I don’t think we should have a feature flag for this. Let’s pick one mutex implementation, unless somehow two of them have very good reasons to be chosen in different sitatuions.

I’d consider another PR to switch unconditionally to std::sync::Mutex, but I’m not confident it’s actually better (or worse!) for us. So if someone is interested in pursuing this, please make benchmarks of string-cache itself (or even better, html5ever), not just of a mutex in isolation.

In particular, I think the "extreme contention" benchmark from rust-lang/rust#95035 (comment) is unlikely to be relevant: we choose between 4096 different mutices based on a string hash, so as far as I can tell contention would only happen if many threads keep interning the very same string and doing nothing else.

Possibly, wrapping these mutices in https://docs.rs/crossbeam-utils/latest/crossbeam_utils/struct.CachePadded.html might help. (Though it’d cost 480 KiB more memory.) That would be nice to try as well if someone makes benchmarks.