Zend: inline some Closure handling

[Girgias]

The initial motivation was to actually remove the get_closure object handler as I couldn't find any usage via SourceGraph (which is quite difficult as get_closure is incredibly common) and the one usage I could was the old Pimple extension and thus effectively revert f90255c

But it turns out that ext/ffi uses it for ZEND_FFI_TYPE_FUNC CData classes (which once again reminds me we should try and actually provide different distinct classes for all those CData types rather than changing object handlers...)

Anyway I've readded the zend_get_closure() API which inlines the Closure and __invoke() behaviour and abstracts over the get_closure object handler logic, and reordered some logic with the new API usage.

[ndossche]

I would expect that the dispatch via a virtual call is invisible in real life applications, and it should be an easily predictable call target for CPUs.

[ndossche]

I don't see benefit in this honestly, especially the code duplication isn't great.
What actually motivated this investigation (other than FCC/FCI APIs, which is semi-orthogonal IMO)?

[Girgias]

I don't see benefit in this honestly, especially the code duplication isn't great. What actually motivated this investigation (other than FCC/FCI APIs, which is semi-orthogonal IMO)?

Trying to determine if it is possible to have the called_scope/calling_scope be constant pointers in the FCC (and elsewhere), which are retrieved via the get_closure handler at times, and trying to follow it through was somewhat hairy.

The other motivation was to determine if, when we get rid of the deprecated callables, we can remove one of the scopes from the FCC.

But I can see the lack of benefit if we can't actually remove the get_closure handler, might still make sense to have zend_get_closure be an always inlined function in the header that just does: return obj->handlers->get_closure && obj->handlers->get_closure(obj, &called_scope, &fbc, &object, check_null) == SUCCESS;