Addresses two problems with itimer lock acquisition being split by an alarm signal:
First, rather than a single lock for all itimers, which is subject to races due to alarms of different types arriving in different threads simultaneously, we switch to using a separate lock per itimer signal type. (We also have to handle an alarm arriving while handling an app itimer syscall, which is why we can't just blindly block and wait for the lock.)
Second, rather than holding a mutex to increment a counter, we switch two different itimer counters to use atomic increments instead. These counters are used for new threads, and an alarm can arrive in a new thread while it's setting up. This avoids having a frequent time window where an alarm splits the lock routine.
Fixes #2993 (closed)