snd_uaudio: Do not use pcm_channel->lock to protect uaudio_chan

[christos]

Summary

This is a layering violation, but it also makes the control flow
confusing; snd_uaudio(4) should have its own lock to protect its
structures.

Fixes: 5cc34a83e1 ("Revert "sound: Merge chn_intr() with chn_intr_locked()"")
Sponsored by: The FreeBSD Foundation
MFC after: 1 week

[markj]

What problem does this fix?

[christos]

In D54102#1236568, @markj wrote:

What problem does this fix?

From the commit referenced in "Fixes" (5cc34a83e1):

It turns out that snd_uaudio(4) uses sound(4)'s channel lock for its USB
transfer callbacks. I will try to address this at some point, because
this is layering violation, but for now we need to revert the commit, as
it causes a lock recursion panic with USB audio devices.

[christos]

In D54102#1236569, @christos wrote:

In D54102#1236568, @markj wrote:

What problem does this fix?

From the commit referenced in "Fixes" (5cc34a83e1):

It turns out that snd_uaudio(4) uses sound(4)'s channel lock for its USB
transfer callbacks. I will try to address this at some point, because
this is layering violation, but for now we need to revert the commit, as
it causes a lock recursion panic with USB audio devices.

Bump.