Replace parking_lot locks with std locks

[xacrimon]

Based on #4408, it needs to be merged first.

Shouldn't have any effects on size and performance from the usage.
Reduced wasm bundle size by 5% on my production project.

[gbj]

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

[lukexor]

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

[gbj]

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.