Benchmark entirely unfair locks for parallel rustc

[bjorn3]

My theory is that the accounting necessary for implementing eventually fair locks in parking lot causes an instruction count increase for parallel rusrc by a couple of percents without improving the wall time. Without this accounting taking a lock should be a matter of a cmpxchg and possibly a futex wait if it was already locked. I don't think it matters as much if a thread is starved for extended periods of time rather than splitting this starving between threads as eventually the thread responsible for the starving will finish it's task and no longer cause any other threads to starve, thus guaranteeing progress. Whether I am right or not will need to be shown using benchmarking. It would also be interesting to see how long a spinlock should happen before falling back to a futex wait, if it should happen at all given that some query locks are probably held for extended periods of time.