core: Remove taking of events lock inside usbi_fd_notification()

It is unnecessary to take the events lock when a thread needs to
interrupt an event handler to receive a change list of poll fds.
It is sufficient to simply write to the control pipe and let the
event handler be notified of this event when it polls.

Taking the events lock inside this function leads to opportunity
for deadlock in certain situations, such as a client program
running on an OS that uses fd notification on each individual
transfer. If the client program were to protect a list of transfers
with a single lock, it could deadlock if that lock were taken in
two separate threads, one which is attempting to submit a new
transfer and one which is executing inside the transfer completion
callback.

Thanks to Dmitry Fleytman and Pavel Gurvich for reporting this.

Signed-off-by: Chris Dickens <christopher.a.dickens@gmail.com>
core: Rename pollfd_modify counter and its lock to device_close

This counter is now solely used for closing a device, so rename
the variable appropriately.

Signed-off-by: Chris Dickens <christopher.a.dickens@gmail.com>
core: Add new lock to protect internal context event data

This lock will be used in subsequent changes that will consolidate
all different event sources (i.e. device close, fd notification,
hotplug message) into a single event.

Signed-off-by: Chris Dickens <christopher.a.dickens@gmail.com>
core: Transition device close event to use event_data_lock

This change removes the device_close_lock and uses the shared event
data lock to protect the value of the device_close counter.

Signed-off-by: Chris Dickens <christopher.a.dickens@gmail.com>
core: Rename pipe used to signal internal events

Signed-off-by: Chris Dickens <christopher.a.dickens@gmail.com>
core: Add helper functions to signal and clear the event pipe

Signed-off-by: Chris Dickens <christopher.a.dickens@gmail.com>
core: Add new flag to record when a new poll fd is added

This flag will be useful in a subsequent commit that further
consolidates event handling.

Signed-off-by: Chris Dickens <christopher.a.dickens@gmail.com>
core: Eliminate hotplug pipe, using list and event pipe instead

To further consolidate libusb internal events, this change removes
the hotplug pipe. Hotplug messages are now kept in a list within the
context, and the event pipe is signalled when a new hotplug message
is added. When handling events, the hotplug messages will be processed
from the list instead of from a separate pipe.

This change is greatly beneficial for the Windows/WinCE backends which
do not allow pipes to be used in the WaitFor* functions.

Signed-off-by: Chris Dickens <christopher.a.dickens@gmail.com>
core: Signal the event pipe at most one time

This change will ensure that the event pipe is only signalled
at most one time during the course of any incoming events. New
events that occur while the event pipe is in the signalled state
will not cause the event pipe to be signalled again.

This change will provide support for the use of native events on
the Windows/WinCE backends, as these events are binary and do not
"count" the number of times they are signalled.

Signed-off-by: Chris Dickens <christopher.a.dickens@gmail.com>