alsa software_latency_max doesn't take into account desired rate

In the alsa backend, `software_latency_max` get calculated as `max_buffer_size/max_rate` which doesn't make sense if I then later open it with a rate that is not the maximum rate.

As an example, my default device is a plug that (in resampling mode, which gets activated since it's not a raw device) says it can do 10000 channels and up to 4294967295Hz, which while is very excessive sure, other applications/libraries handle that just fine and give non choppy audio. libsoundio comes up with some max latency of 0.0002, ends up choosing 0, and audio output sounds like garbage. Disabling the clamp allows it to use something like 0.1 with no issues.

(Also if I set my default device to use the hw device and not a plug, libsoundio just outputs no audio at all while other applications again work fine.)

The latency calculation should probably be moved to stream opening, since the values it calculates during it's probe doesn't correspond to what you open the stream with. This is also probably fine to do since according to the documentation: **"For PulseAudio and WASAPI this value is unknown until you open a stream."**, so it's pretty much already guaranteed you can't rely on it before opening in the two probably most used backends.