[roll] Roll fuchsia [usb][audio] Fix a bookkeeping error.

Fix issues with the frame number accounting for isochronous audio
packets in the current usb audio driver.

First, this code was not quite correct.

```
usb_frame_num_ = std::max(
    usb_frame_num_++,
    usb_get_current_frame(&parent_.usb_proto()));
req->header.frame = usb_frame_num_;
```

It is attempting to compute the next frame number to apply to a
packet, but it does not want to fall behind what the USB host
controller reports as the next schedule-able frame number number.  So,
it is trying to assign `usb_frame_num_` to either the next number in
the sequence, or the next schedule-able frame number, whichever is
larger.

Unfortunately, it is using the postfix ++ operator.  This is going to
return the pre-incremented value of usb_frame_num_, not the next
number in the sequence.  As a result, it will fail to increment the
frame numbers at all, until the safe index reported by the host
controller has caught up to the value of usb_frame_num_.  Thereafter,
the variable will simply track the value being reported by the host
controller driver.

So at startup, if the safe-start-index reported by the controller
driver is X, we will end up sending our starting packets each with a
Frame ID of X (presuming that the HW does not advance the frame index
during the initial burst).

If the controller supports the "Contiguous Frame ID Capability" (this
is mandatory for XHCI 1.1 and beyond), this seems like it should cause
the controller to skip the second and subsequent packets (declaring
"Missed Service Errors" for each) until we  catch up to a point in the
stream where the packets are finally tracking the frame index
register, and at that point in time, we should be right on the edge of
underflow.

OTOH - If CFC is not supported, then this startup issue should work
out.  If we start to fall behind, however, and end up skipping packets
in the stream because of this check, that will end up getting us out
of sync with where we are copying data from the ring buffer being
populated by the mixer which can cause its own problems.

For now, simply fix the increment operation, and do not attempt to
floor the value with the safe index reported by the controller.  If we
start to fall behind, we will either totally underflow (and will need to
restart the stream entirely), or the packets will end up getting
skipped, but the stream should retain the proper position relative to
the ring buffer (assuming CFC == 1)

Original-Bug: 102058
Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/707866
Original-Revision: 396a98365c629c221cf1f3fbc2f022f096933ea4
GitOrigin-RevId: e6f3d78130737b99c9502c7d7f315d19464be5f2
Change-Id: Ie220809552f27b58cb680a9b327797c1331498fe