Kernel alarms pass the alarm ID

So userspace can tell which of it's #A alarms is firing.  With this (and
with multiple event handlers per event), we could have multiple alarm
handlers register and run dynamically.  Alternatively, we could switch
based on the ID, if there was one common handler (can do that
statically).

Note that the existing alarm examples can receive multiple events for
the same alarm.  It's up to userspace to handle that (it's easy, and we
do it).  This is a consequence of using SPAM_PUBLIC.  If your alarm
can't handle that, use an INDIR/FALLBACK.  This is part of the reason
why I didn't make a helper to set up all the alarm stuff - people will
want to customize, especially in the realm of the ev_q.  (The other
issue is whether or not CLOEXEC is used.  And there may be other issues
I haven't thought of).

Multiple ev_qs can be registered for different alarms; it's just hard to
share the event handler for them all, hence this patch.  I'll deal with
this more if we ever get someone who wants to use multiple kernel alarms
with different handlers.