Use Crystal::PointerLinkedList instead of Deque in Mutex

[ysbaddaden]

Follows WaitGroup that uses a linked list instead of a deque to store the waiting fibers.

The flat array doesn't have much impact on performance: we only reach the head or the tail once to dequeue/dequeue one fiber at a time. This however spares a number of GC allocations since the Deque has to be allocated plus its buffer that will have to be reallocated sometimes (and will only ever grow, never shrink).

Extracts the undocumented Fiber::Waiting struct from WaitGroup that acts as the node in the linked list.

Renames @lock to @spin since the former was a bit confusing, for example with @lock_count that counts the number of reentrancy.

[BlobCodes]

This PR seems to remove the need for @queue_count since PointerLinkedList#empty? should be just as fast

[ysbaddaden]

Well Deque#empty? would have been just the same.

What we really need is to know whether there's a waiter and it must be atomic, so unlock can safely spare acquiring the spinlock when there are no waiters.

Now, we don't need to count: it could be a simple flag on the spinlock value, set when #lock acquires the spinlock and unset when #unlock releases it and there are no waiters (this is what the nsync library does).