Replace parking_lot locks with std locks - #4410

Thanks; I found the same binary size effect and removed all the parking_lot locks from the reactive crate long ago, but must've not realized I had these ones in tachys/the renderer.

The house style is to use .or_poisoned() (the OrPoisoned trait) to unwrap locks so it is clearer at a glance that it's distinct from other .unwrap() calls

Has anyone read this? https://blog.cuongle.dev/p/inside-rusts-std-and-parking-lot-mutexes-who-win

Not sure what the lock contention is like for a typical leptos app to gauge the better choice here or what proportion of locking is happening in wasm vs the server (when using SSR) where thread contention actually matters

There should be effectively zero lock contention for the cases covered by this PR. In the tachys case there will be zero contention, and either kind of lock will actually panic in the frontend if there are conflicts. In the other cases, it's mostly reading from/writing to ResponseOptions, which a typical request would do in 0 or 1 places. Contention would consist of something like "I am trying to write into ResponseOptions from within m different Suspense components which have been spawned onto n different tokio worker threads, simultaneously" and so the worst real case I can imagine for these would be well within the "low to moderate contention" scenario where std outperforms parking_lot in the linked article's benchmarks.