Use real / libc locks in the codebase

[Byte-Lab]

All of the locks used in JCoz are home-grown spinlocks + memory fences. The original intention here was to get the profiler out of the way of the program as quickly as possible, and spinlocks avoid the overhead of making syscalls or being descheduled by the kernel. Realistically, this was wrong for several reasons:

1. Some of the logic we do in the code is non-trivial. For example, we take the frame_lock when populating the vector of frames that were collected by user threads. This could result in dynamic memory allocations. This should just be a mutex.
2. libc mutexes are pretty heavily optimized at this point. They often do atomics and some minimal spinning to check if a lock is free or will be free soon, and then otherwise use a futex to sleep. This is much more efficient for the overall runtime of the system.
3. Linus Torvalds recently wrote about how using spin locks in userspace is not a good idea, which I agree with: https://www.realworldtech.com/forum/?threadid=189711&curpostid=189723. Even if we knew that some critical section was tiny, the kernel scheduler could just come in and deschedule us anyways.

Let's just use normal locking primitives.