epoll: fix up lock ordering issues

epoll suffers from a basic lock ordering issue: epoll_ctl() needs to
protect against concurrent adds, so it needs an epoll-wide lock to be held
during these operations, which also involve the polled file's lock.  On the
other hand, when a polled file has an event, already holding its own lock,
it wants to enqueue it to all epollers, it needs the epoll's lock to protect
the _activity data structure.

Fix by splitting epoll_file::f_lock into two: f_lock is used to protected
epoll_file::map (used for epoll_ctl), while a new _activity_lock is used
to protect _activity and the rest of the notification side.

This simplifies a lot of code and prevents some races, and allows us to fix
up the close() path.

Reviewed-by: Tomasz Grabiec <tgrabiec@gmail.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>