more user friendly API additions for obscure functions

[aloistr]

Work on php-sweph inspired me to look deeper into the existing SwissEph perl module.
I have taken over the concept of compiling SE library directly into the perl module, instead of relying on the installed
libswe.so (or DLL). This has pro- and contras.

Something else cam to my attention:
functions like
swe_lun_occult_when_loc($tjd_ut, $ipl, $star, $iflag, $ifltype, $backw, $geopos);
have more eplicit return hashes in perl.
Instead of arrays with numbered indices like in C, the perl function in addition to the arrays tret and attr also
named hash fields with the data unpacked in a meaningful way:
-> ecl_maximum time of maximum occultation (UT)
-> t1st_contact
-> t2nd_contact
-> t3rd_contact
-> t4th_contact
-> disc_ratio size ratio of the two discs
-> fraction_diameter percentage of diameter occulted
-> fraction_disc percentage of disc occulted
-> core_shadow_km diameter of core shadow (km, negative
with total, positive with annular ecl.)
-> body_azimuth
-> body_alt_true
-> separation_angle

This might also be done for php-sweph.
It will not break the existing API, because extra named array fields will not hurt.
The same field names as in Perl should be used.

[kevindecapite]

We could go even further and return an object for cases like this. With typehinting, this would make for a very robust extension that is easy to use.

Refs:

• https://www.phpinternalsbook.com/php5/classes_objects.html
• https://github.com/aloistr/perl-sweph/blob/master/SwissEph.xs