Block: Add the BFQ-v5 I/O scheduler to 3.1

The general structure is borrowed from CFQ, as much code. A
(bfq_)queue is associated to each task doing I/O on a device,
and each time a scheduling decision has to be taken a queue is
selected and it is served until it expires.

    - Slices are given in the service domain: tasks are
      assigned budgets, measured in number of sectors. Once got
      the disk, a task must however consume its assigned budget
      within a configurable maximum time (by default, the
      maximum possible value of the budgets is automatically
      computed to comply with this timeout). This allows the
      desired latency vs "throughput boosting" tradeoff to be
      set.

    - Budgets are scheduled according to a variant of WF2Q+,
      implemented using an augmented rb-tree to take
      eligibility into account while preserving an O(log N)
      overall complexity.

    - A low-latency tunable is provided; if enabled, both
      interactive and soft real-time applications are
      guaranteed very low latency.

    - Latency guarantees are preserved also in presence of NCQ.

    - High throughput with flash-based devices, while still
      preserving latency guarantees.

    - Useful features borrowed from CFQ: cooperating-queues
      merging (with some additional optimizations with respect
      to the original CFQ version), static fallback queue for
      OOM.

    - BFQ supports full hierarchical scheduling, exporting a
      cgroups interface.  Each node has a full scheduler, so
      each group can be assigned its own ioprio and an
      ioprio_class.

    - If the cgroups interface is used, weights can be
      explictly assigned, otherwise ioprio values are mapped
      to weights using the relation
      weight = IOPRIO_BE_NR - ioprio.

    - ioprio classes are served in strict priority order,
      i.e., lower priority queues are not served as long as
      there are higher priority queues.  Among queues in the
      same class the bandwidth is distributed in proportion to
      the weights of each queue. A very thin extra bandwidth
      is however guaranteed to the Idle class, to prevent it
      from starving.

Signed-off-by: Paul Beeler <sparksco@gmail.com>