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

In a code-cleanup phase, we introduced the following errors in the
heuristic for detecting when an application is soft real-time:
. We started (properly) to use the macro time_is_before_jiffies() to
  take wraparound issues into account, but such a macro easily returns
  anomalous results if its argument is equal to the value that we used
  as an approximation of 'infinity', namely ((unsigned long) (-1)).
  The consequence was that the logical expression used to determine
  whether a queue belongs to a soft real-time application often yielded
  an incorrect result. In the end, some application happened to be
  incorrectly deemed as soft real-time and hence weight-raised. This
  affected both throughput and latency guarantees.
. In an attempt to use the above macro in a logical expression we made a
  scriverner's error.

In addition, we realized that:
. On the expiration of a queue, the condition that allowed a
  weight-raising period to start, in case the queueu was soft
  real-time, was not the most general one. In particular, this could
  uncorrectly prevent an empty queue from being deemed as soft
  real-time.
. Jiffies-comparison macros were not used in the following cases, whereas
  they had to:
  . to establish whether an application initially deemed as interactive
    is now meeting the requirements for being classified as soft
    real-time;
  . to determine if a weight-raising period must be ended.
. The type of the time quantities used in the weight-raising heuristics
  was u64, whereas the type of the time (jiffies) is unsigned long.
. There were some typos in the wrais-related log messages.
. The next_active and active_entity field of the bfq_sched_data data
  structure did not follow the new naming convention introduced with v7.

This commit tries to address and fix all the above issues and problems.

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