shared/loop-util: spin on LOOP_CTL_REMOVE

If we call LOOP_CLR_FD and LOOP_CTL_REMOVE too rapidly, the kernel cannot deal
with that (5.3.13-300.fc31.x86_64 running on dual core
Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz).

$ sudo strace -eioctl build/test-dissect-image /tmp/foobar3.img
ioctl(3, TCGETS, 0x7ffcee47de20)        = -1 ENOTTY (Inappropriate ioctl for device)
ioctl(4, LOOP_CTL_GET_FREE)             = 9
ioctl(5, LOOP_SET_FD, 3)                = 0
ioctl(5, LOOP_SET_STATUS64, {lo_offset=0, lo_number=0, lo_flags=LO_FLAGS_READ_ONLY|LO_FLAGS_AUTOCLEAR|LO_FLAGS_PARTSCAN, lo_file_name="", ...}) = 0
ioctl(5, BLKGETSIZE64, [299999744])     = 0
ioctl(5, CDROM_GET_CAPABILITY, 0)       = -1 EINVAL (Invalid argument)
ioctl(5, BLKSSZGET, [512])              = 0
Waiting for device (parent + 0 partitions) to appear...
Found root partition, writable of type btrfs at #-1 (/dev/block/7:9)
ioctl(5, LOOP_CLR_FD)                   = 0
ioctl(3, LOOP_CTL_REMOVE, 9)            = -1 EBUSY (Device or resource busy)
Failed to remove loop device: Device or resource busy

This seems to be clear race condition, and attaching strace is generally enough
to "win" the race. But even with strace attached, we will fail occasionally.
Let's wait a bit and retry. With the wait, on my machine, the second attempt
always succeeds:

...
Found root partition, writable of type btrfs at #-1 (/dev/block/7:9)
ioctl(5, LOOP_CLR_FD)                   = 0
ioctl(3, LOOP_CTL_REMOVE, 9)            = -1 EBUSY (Device or resource busy)
ioctl(3, LOOP_CTL_REMOVE, 9)            = 9
+++ exited with 0 +++

Without the wait, all 64 attempts will occasionally fail.