The value INVALID_HANDLE_VALUE could in theory be a valid memory address,
so the analyzer is confused and thinks either we have a memroy leak
or we try to free a fixed address.
The used method for initalizing and registering the handle creators
had certain disadvantages like that it was necessary to have the creators
initialized before the first call to CreateFile. In case of comm it
wouldn't have been possible to open an comm port without calling any
other call related function first.
Now the handle creators are initialized the first time CreateFile is
called. This way it is also possible to ensure a certain order of the
handler invocations.
This commit also splits out the client side named pipe code from
the generic file handling (now called generic.c instead of file.c) and
uses the new handle creator infrastructure to register.
Allows the WinPR HANDLE functions WaitForSingleObject and
WaitForMultipleObjects to signal in case of write events.
This is used by CreateFileDescriptor and SetEventFileDescriptor,
which got an API change accomodating for this new feature.
RegisterHandleCloseCb() is also useful to don't get a circular dependency, a better synchronization must be find out...
This reverts commit 8f3b3fa573.
Since commit 5e09e37d42 was basically unfixable,
here is a slightly different approach that should hopefully solve all
discovered issues and race conditions.
