minor change in RoutingTable::NthElementSortFromTarget

minor change in RoutingTable::NthElementSortFromTarget
There are a couple of issues here now.

The first is that we should only be using `std::partial_sort` for GCC < 4.8.3.  The current implementation causes any version of GCC and also any version of Clang to use `partial_sort`.

The second is that we're using two different elements as the target in `partial_sort` vs `nth_element` (`nodes_.begin() + nth_element` for the former, `nodes_.begin() + nth_element - 1` for the latter).  I expect this is a mistake.

I would expect a function called `NthElementSortFromTarget` having `unsigned int nth_element` as a parameter to use `nodes_.begin() + nth_element`, *not* `nodes_.begin() + nth_element - 1`!

This off-by-one error probably explains the test results you were seeing.  For example:

    #include <algorithm>
    #include <iostream>
    #include <vector>

    int main() {
      std::vector<int> v = { 1, 8, 5, 2, 4, 3, 9, 0, 6, 7 };
      std::cout << "Vector at start ==    ";
      for (int i : v)
        std::cout << i << " ";
      std::cout << '\n';

      for (size_t n(0); n < v.size(); ++n) {
        std::nth_element(std::begin(v), std::begin(v) + n, std::end(v));
        std::cout << "For n == " << n << ", vector ==";
        for (int i : v)
          std::cout << " " << i;
        std::cout << ", and nth_element is " << v[n] << '\n';
      }
      return 0;
    }

With MSVC 2013, the output from this is:

    Vector at start ==    1 8 5 2 4 3 9 0 6 7
    For n == 0, vector == 0 1 2 3 4 5 6 7 8 9, and nth_element is 0
    For n == 1, vector == 0 1 2 3 4 5 6 7 8 9, and nth_element is 1
    For n == 2, vector == 0 1 2 3 4 5 6 7 8 9, and nth_element is 2
    For n == 3, vector == 0 1 2 3 4 5 6 7 8 9, and nth_element is 3
    For n == 4, vector == 0 1 2 3 4 5 6 7 8 9, and nth_element is 4
    For n == 5, vector == 0 1 2 3 4 5 6 7 8 9, and nth_element is 5
    For n == 6, vector == 0 1 2 3 4 5 6 7 8 9, and nth_element is 6
    For n == 7, vector == 0 1 2 3 4 5 6 7 8 9, and nth_element is 7
    For n == 8, vector == 0 1 2 3 4 5 6 7 8 9, and nth_element is 8
    For n == 9, vector == 0 1 2 3 4 5 6 7 8 9, and nth_element is 9

and with Clang on OS X:

    Vector at start ==    1 8 5 2 4 3 9 0 6 7 
    For n == 0, vector == 0 1 2 3 4 5 9 8 6 7, and nth_element is 0
    For n == 1, vector == 0 1 2 3 4 5 9 8 6 7, and nth_element is 1
    For n == 2, vector == 0 1 2 3 4 5 9 8 6 7, and nth_element is 2
    For n == 3, vector == 0 1 2 3 4 5 9 8 6 7, and nth_element is 3
    For n == 4, vector == 0 1 2 3 4 5 9 8 6 7, and nth_element is 4
    For n == 5, vector == 0 1 2 3 4 5 9 8 6 7, and nth_element is 5
    For n == 6, vector == 0 1 2 3 4 5 6 7 8 9, and nth_element is 6
    For n == 7, vector == 0 1 2 3 4 5 6 7 8 9, and nth_element is 7
    For n == 8, vector == 0 1 2 3 4 5 6 7 8 9, and nth_element is 8
    For n == 9, vector == 0 1 2 3 4 5 6 7 8 9, and nth_element is 9

It looks like MSVC always sorts the full vector (at least for this small example), hence it was always accidentally causing the test to pass.  But for Clang, if we look at the output where `n` is 5 and imagine we've called our function with `nth_element` as 6, then we'll clearly get the wrong result when we look at `begin() + 6` outside the function again (would be 9 instead of 6).