Remove the old FIFO socket from the event queue when recreating it

I narrowed down the cause of the log spamming behaviour I observed while looking at #649.  strace of the master process looked like this:

```
epoll_wait(134, {{EPOLLHUP, {u32=135, u64=135}}}, 1, 1000) = 1
read(135, "", 1)                        = 0
close(135)                              = 0
unlink("/tmp/fifo0")                    = 0
mknod("/tmp/fifo0", S_IFIFO|0600)       = 0
open("/tmp/fifo0", O_RDONLY|O_NONBLOCK) = 135
fcntl(135, F_GETFL)                     = 0x8800 (flags O_RDONLY|O_NONBLOCK|O_LARGEFILE)
fcntl(135, F_SETFL, O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 0
epoll_ctl(134, EPOLL_CTL_ADD, 135, {EPOLLIN, {u32=135, u64=135}}) = 0
write(2, "Tue Jun 24 13:39:27 2014 - chain"..., 66) = 66
wait4(-1, 0x7fff1b5d490c, WNOHANG, NULL) = 0
epoll_wait(134, {{EPOLLHUP, {u32=135, u64=135}}}, 1, 1000) = 1
read(135, "", 1)                        = 0
close(135)                              = 0
unlink("/tmp/fifo0")                    = 0
mknod("/tmp/fifo0", S_IFIFO|0600)       = 0
open("/tmp/fifo0", O_RDONLY|O_NONBLOCK) = 135
fcntl(135, F_GETFL)                     = 0x8800 (flags O_RDONLY|O_NONBLOCK|O_LARGEFILE)
fcntl(135, F_SETFL, O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 0
epoll_ctl(134, EPOLL_CTL_ADD, 135, {EPOLLIN, {u32=135, u64=135}}) = 0
... etc ...
```

The cause was the master fifo being recreated all the time.  For some reason, it appears that if the fd was left inside epoll while the socket was being recreated (but hadn't been recreated *yet*), epoll_wait() would immediately say that the fd is ready to be read from.

I haven't been able to reproduce the bug with this fix, but I wonder if that's just a coincidence; I have no experience with FIFO programming and I can't seem to find a definite source on how programs are supposed to do what uWSGI is attempting here.

Any thoughts?