WGS84 intermediary transformations in non geographic CRS pairs

[bosborn]

• CompoundCoordinateTransform implementation
• Intermediary transformations to WGS84 when CRS source or target has transform to WGS84 parameters and the other is not a geographic CRS, similar behavior to proj4js

FIXES #32

[pomadchin]

@bosborn hm, I'm wondering, what is the original osgeo/proj behavior?

It could be that some param is incorrectly set / re-used / initialized (I don't know for sure, that is a blind guess from my previous experiences of fixing projections behaviors).

[bosborn]

@pomadchin Spent some more time today and I came up with a different algorithm integrated solution that passes all tests in this new pull request. #76

A compound conversion was definitely not my first choice, but what I came up with after some of these attempts.

I did not find any result changing differences in the algorithms in osgeo/proj (proj.4 version 5.2).

pj_datum_transform pj_Convert_Geocentric_To_Geodetic latitude calculation

There had been a few changes to pj_Convert_Geocentric_To_Geodetic (avoid zero division and atan2 instead of atan). I also ported the non iterative pj_Convert_Geocentric_To_Geodetic method but the results were the same.

Let me know what you think of #76 as an alternate solution to this compound implementation.