block: Switch from BFQ-v7r1 for 3.12.0 to BFQ-v7r2 for 3.12.0

1) BUGFIX/IMPROVEMENT. One of the requirements for an application to be
   deemed as soft real-time is that it issues its requests in batches, and
   stops doing I/O for a well-defined amount of time before issuing a new
   batch. Imposing this minimum idle time allows BFQ to filter out I/O-bound
   applications that may otherwise be incorrectly deemed as soft real-time
   (under the circumstances described in detail in the comments to the
   function bfq_bfqq_softrt_next_start()). Unfortunately, BFQ could owever
   start counting this idle time from two different events: either from the
   expiration of the queue, if all requests of the queue had also been already
   completed when the queue expired, or, if the previous condition did not
   hold, from the first completion of one of the still outstanding requests.
   In the second case, an application had more chances to be deemed as soft
   real-time.
   Actually, there was no reason for this differentiated treatment. We
   addressed this issue by defining more precisely the above requirement for
   an application to be deemed as soft real-time, and changing the code
   consequently: a well-defined amount of time must elapse between the
   completion of *all the requests* of the current pending batch and the
   issuing of the first request of the next batch (this is, in the end, what
   happens with a true soft real-time application). This change further
   reduced false positives, and, as such, improved responsiveness and reduced
   latency for actual soft real-time applications.
2) CODE IMPROVEMENT. We cleaned up the code a little bit and addressed
   some issues pointed out by the checkpatch.pl script.

Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>