firewire: core: make transaction label allocation more robust

If one request is so long-lived that it does not get a response before
the following 63 requests, its bit in tlabel_mask is still set when the
next request tries to allocate a transaction label for that number.  In
this state, while the first request is not completed or timed out, no
new requests can be submitted.

To fix this, skip over any label still in use, and do not error out
unless we have entirely run out of labels.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>