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?
Thanks for updating the new code. My comment was mainly because I thought the old code was changed, but it was indeed a similar fragment. Sorry for the confusion.

> Though I wasn't be so sure that BG should work for ttmath in general. 

Yes it is the intention that ttmath should work in general. Because in during review period this is one our the mentioned methods of tackling robustness.

In the meantime we have more methods for robustness now, so relatively it is less important. But still, things which worked for ttmath should still work, that is why I made the comment. And besides that we should still let it work for new code too, though that has less priority.

For example union/intersection also work (worked) with ttmath code. I should check it again, as said they are not automatically unit tested and my personal daily development platform is moved from Windows to Linux...