Feature/geographic

The purpose of this PR is to move an algorithm resolving vincenty inverse problem outside of the vincenty strategy.

The goal was to add the algorithm a way of calculating not only distance but also forward and reverse azimuths and in the same time to reuse as much code as possible. I implemented a class performing a common part of the algorithm in the ctor and allowing to calculate desired result with member functions. This way it's possible to e.g. calculate the distance and azimuth without recalculating most of the intermediate values:

    vincenty_inverse<CT> vi(lon1, lat1, lon2, lat2, spheroid);
    vi.distance();
    vi.azimuth12();

The next step is to move the vincenty and andoyer strategies out of the extensions. Since Vincenty's algorithm could be used one way or another in various strategies would it be a good idea to rename it (e.g. to `vincenty_distance`)? Or would you prefer to leave the name `vincenty` for a distance strategy and pick some suitable names for possible other strategies in the future?
Yes, the different approach is used in the new code (vincenty_direct). The moved one was untouched. Both works for (the old?) ttmath from extensions (after a fix).

Though I wasn't be so sure that BG should work for ttmath in general. E.g. I was forced to fix haversine. side_by_cross_track still doesn't compile because when I tried to add a fix the test failed so I reverted it. In vincenty test I got very different results WRT results for doubles so I dug a little and what I found was that ttmath default constructor sets the object to NaN (it may be not the only reason). According to http://en.cppreference.com/w/cpp/language/value_initialization in C++03 for:

    T n = T(); // default ctor in C++03, NOT 0

the default ctor is called. Therefore:

    assert(n == T(0)); // FAILS for ttmath

In many places in the library it's assumed that the value-initialization sets the value to 0, which may be wrong for user-defined types. E.g. math::abs() implementation looks like this:

    T const zero = T();
    return value < zero ? -value : value;

It doesn't work properly for ttmath. This is why we should explicitly initialize objects with values, e.g.:

    T n1(0);
    T n3 = T(0);
    T n2 = 0;

Furthermore we shouldn't assume that any value-initialized object would contain zeros, e.g. an object of type model::point<> defining empty default ctor.

This was just a side note. This PR is not a good place for fixing initializations.