ucode: Add 'operator execute'

[IdWV]

It can be useful to call a resource as if it was a function. This commit adds a way to do so.

When a non-callable is supplied to uc_vm_insn_call(), and it is an object or has a prototype, then the object/prototype stack is searched for a callable named 'operator()', and if found, that is called instead.

So in the script
var(...); is a functional synonym to var'operator()';

[jow-]

I like the idea, it goes into the direction of Lua's metamethods.

A couple of remarks:

1. We already have a tostring "metamethod" which is used to obtain a string representation of a resource/object/array, so the function making a resource callable should follow a similar naming convention. I'd lean towards a simple invoke or similar property name instead of operator() which is more C++-esque
2. We need to decide if an invoke metamethod may be another object with an invoke metamethod (loops!) or whether it must be a true function or cfunction
3. The ucv_is_callable() API function needs to report such values-with-invoke-metamethod as callable too
4. You can use ucv_property_get(val, "propname") to find a property in the object itself or its prototype chain
5. The arbitrary search depth limitation of 16 should be removed, it could lead to unexpected behavior with very deep prototype chains
6. In case of dictionaries, I am not sure if we should look for the invoke "metamethod" in the dictionary itself. I think it is better to only search it in the prototype chain, this way user objects will not accidentally trigger this behavior as prototypes are rare and explicitly set while plain dictionaries may be constructed from any number of sources.

[IdWV]

1. To avoid unwanted collisions, I first thought about using some GUID or so. But I decided 'operator()' is rare enough to be not used by accident.
   On the other hand, if an object has an executable member 'invoke', than it's designed to be invoked, and the function doesn't (need to) know it's name is omitted in the script. The behaviour is the same. So that won't hurt.
2. Not only loops, also branches. An object could have an non-executable invoke member, which has an executable invoke member in its prototype chain. Meanwhile the object can have an executable invoke in it's own chain either.
   Further the 'this' needs to make sense to the invoke function. The more complex the construction, the more ways to screw it up. So I tend toward keeping the chain a chain, and not making it a tree.
3. When using ucv_prototype_get() a non-executable invoke can hide an executable one. Is that wanted behaviour?
4. Shouldn't the prototype chain be guarded against loops, in that case?
5. 'accidentally trigger this behavior'. The behaviour is in this case not throwing an "left-hand side is not a function", but executing a member function instead. Unless someone wrote a script which relies on that exception to be thrown, it won't break existing scripts. But i can imagine that for new scripts this can cause some head-scratching. I'm fine with restricting this to the prototype chain.

[IdWV]

The ucv_is_callable() API function needs to report such values-with-invoke-metamethod as callable too

Is is OK to change the inline function to an exported function?

[jow-]

Yes, should be fine