Remove the bio_empty_barrier() check

**NOTE:** this branch needs 962020a5ff1dd87cc0003cc295fcb600f61e5c31 in order to build correctly. See #1317. In addition, I did not check whether the resurrected flush code actually works correctly.

To determine whether the kernel is capable of handling empty barrier BIOs, we check for the presence of the `bio_empty_barrier()` macro, which was introduced in 2.6.24. If this macro is defined, then we can flush disk vdevs; if it isn't, then flushing is disabled.

Unfortunately, the `bio_empty_barrier()` macro was removed in 2.6.37, even though the kernel is still capable of handling empty barrier BIOs.

As a result, flushing is effectively disabled on kernels >= 2.6.37, meaning that starting from this kernel version, zfs doesn't use barriers to guarantee on-disk data consistency. In other words, it behaves as if `zfs_nocacheflush` was set. This is quite bad and can lead to potential data corruption on power failures.

This patch fixes the issue by removing the configure check for `bio_empty_barrier()`, as we don't support kernels <= 2.6.24 anymore.

Thanks to Richard Kojedzinszky for [catching this nasty bug][report]. Note that this could also explain why [Phoronix was so skeptical in their benchmarks][bench]:

> However, by the margins that ZFS was faster, one would have to wonder whether it is properly synchronizing to the disk.

  [report]: https://groups.google.com/a/zfsonlinux.org/d/msg/zfs-discuss/DKweF6DtaMo/zn6WDNV3OIgJ
  [bench]: http://www.phoronix.com/scan.php?page=article&item=linux_zfs_june2012&num=2