The sem_wait() call was just a bad idea after-all

The sem_wait() call from vdd_read() that was fixed in the previous commit to this file was a bad idea to begin with:
There is (often) not a 1:1 ratio of bytes in the receive ring buffer and the semaphore count, so we'd often halt here waiting for the semaphore to be signaled even though there were still characters in the receive buffer. This caused (new) stalls/hangs in keyboard input in DOS door games. We didn't see this previously because the sem_wait() call just didn't work (wrong semaphore pointer value).

Now, call sem_trywait_block() in vdd_read(), but only if the RingBufRead() returned 0 (no bytes read) and even then, only block/wait for a maximum of 30 seconds (same as X00 FOSSIL driver). This blocking behavior is specified for FOSSIL function 02h (Get received character with wait) and would not have worked previous to the previous "fix", so now we have that corrected behavior too. The FTSC spec says the wait is indefinite, but I think a 30 second timeout (ala X00) is more reasonable.

Log the git brach/hash instead of the old CVS revision.

GetMailSlotInfo() apparently always fails on Windows 7 with error 87 (even using Microsoft's own sample code), so lower the log message severity of that failure from ERR to DEBUG. Apparently this is pretty harmless anyway as nothing really needs the write-mailslot status. <shrug>