Improve cache in getproperty for GAPFuncsType

[fingolfin]

That cache is problematic, because it will become out of date if the identifier is changed on the GAP side.

This problem could be avoided, while still retaining most of the performance gain (which in turn I believe mostly stems from avoiding to convert a jl_symbol into a GAP string object), if instead of caching the function pointer, we cached the GAP GVar (an plain UInt value). Then that GVar value can be used to efficiently retrieve the currently assigned value, if any.

This cache of GVar values then could also be used in other places that want to give access to gap global variables.

[fingolfin]

Of course it might be useful to benchmark the various approaches. Code which needs optimal performance should also copy the function out, i.e. myfunc = GAP.GAPFuncs.myfunc, then call that. So I'd compare that in the benchmark, too. I'd do it now, except for the crashes, see PR #121

[fingolfin]

So one argument for keeping the cache as-is, which I overlooked before, is that each GAP object is wrapped into a Julia GapFunc object. But I wonder why: couldn't the Julia function call function simply be defined for MPtr instead? Since creating a GapFunc performs no additional error checking, there seems to be no convenience lost, is there?

[sebasguts]

Well, technically we could overload the () operator for all MPtr, no problem. I think this is a sensible addition anyway.

The caching is of course done for speedup only, but you are right, it is potentially dangerous. I would suggest the following:

• Drop the GapFunc type.
• Rename the GAPFuncs variable into something like GAPObjs, and do the caching with the gvarnum.
• Allow calling all GAP objects, for better or worse (as GAP does anyway)

What do you think?

[fingolfin]

Sounds good to me. One more remark, though: all the other "convenience" wrappers for GAP functionality from within Julia are now in LibGAP.jl/src/gap.jl, only the "call function" one is in JuliaInterface/julia/gaptypes.jl. I don't see a reason for that, and would suggest moving it to LibGAP.jl, too.