wasapi: Various fixes and a workaround for a specific driver bug

commit bc4bbbf6:

wasapisrc: Fix glitching and clock skew issues
We were miscalculating the device period, i.e. the number of frames
we'll get from WASAPI in each IAudioClient::GetBuffer call, due to
a calculation mistake (truncate instead of round).

For example, on my machine when the aux input is set to 44.1KHz, the
reported device period is 101587, which comes out to 447.998 frames
per ::GetBuffer call. In reality we will, of course, get 448 frames
per call, but we were truncating, so we expected 447 and were
discarding one frame every time. This led to glitching, and skew over
time.

Interestingly, I can only see this with 44.1Khz. 48Khz/96Khz are fine,
because the device period is a more 'even' number.

Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/806

commit 6ca06407:

wasapisrc: Clarify that nBlockAlign is actually bpf
bpf = bytes per frame.

commit 0d9a3f12:

wasapisrc: Fix capturing from some buggy audio drivers
Some audio drivers return varying amounts of data per ::GetBuffer
call, instead of following the device period that they've told us
about in `src_prepare()`.

Previously, we would just drop those extra buffers hoping that the
extra buffers were temporary (f.ex., a startup 'burst' of audio data).
However, it seems that some audio drivers, particularly on older
Windows versions (such as Windows 10 1703 and older) consistently
return varying amounts of data.

Use GstAdapter to smooth that out, and hope that the audio driver is
locally varying but globally periodic.

Initially reported in https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/808

commit 97b3adce:

wasapisrc: Try harder to avoid debug output in the hot loop
The whole `src_read()` function is a hot loop since the ringbuffer
thread is waiting on us, and printing to the console from inside it
can easily cause us to miss our deadline.

F.ex., if you had GST_DEBUG=3 and we accidentally missed a device
period, we'd trigger the "reported glitch" warning, which would cause
us to miss another device period, and so on. Let's reduce the log level
so that GST_DEBUG=3 is more usable, and only print buffer flag info when
it's actually relevant.

commit 00ddcf52:

wasapisrc: Correctly handle BUFFERFLAGS_SILENT
We need to ignore the data we get from WASAPI in this case and write
out silence (zeroes).

Initially reported at https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/808

Fixes #806 (closed), and implements most of #808