Expose max buffer size for WASAPI

[sockmaster27]

When a stream is built with an unknown buffer size, it would be very useful to get at least an upper limit, so that any intermediate buffers can be constructed up front. The WASAPI host already appears to have access to such a value through the IAudioClient::GetBufferSize method. However, this is only available after the client has been initialized, which requires some information from the config, which is only available during the call to build_output_stream.

As I see it, these are the possible ways that this could be achieved:

1. Putting this value in the OutputCallbackInfo. I don't think this would be optimal, as it would force some setup logic into the callback, likely behind an if first_run or something.

2. Either obtaining an IAudioClient2 or higher that exposes the IAudioClient2::GetBufferSizeLimits before it is initialized, or initializing the IAudioClient early, and using the IAudioClient::GetBufferSize method.
   Both of these require a WAVEFORMATEX, which needs some info from the config (channels, sample rate, etc.). One solution would be simply feeding it back its own list of supported configs and finding the biggest value, but this seems a bit inefficient and imprecise, since a more appropriate value could have been gotten by knowing the actual configuration.

3. Altering the API by breaking up the build_output_stream method. One part initializes the client and returns the max buffer size, allowing the intermediate buffers to be constructed, and another part takes the callback closure with ownership of the buffers. These could even coexist with the current method.

[chipnertkj]

I'm bumping this, as there is still no API for getting the actual buffer size used by a stream.
Adding to the issue, WASAPI does not respect BufferSize::Fixed values set through a StreamConfig. AFAIK, WASAPI then creates a buffer that's at least the requested size. You're out of luck if you need to know what size that is before playback.
Right now the only way to know is to check the length of the buffer supplied by the data callback of a stream. This, as mentioned in the original post, is not ideal. Whether this is even true for all hosts is not clarified in the documentation.

I'm not sure if any other hosts behave like this, but the library would benefit from some kind of support for this behavior.