More robust hoc error recovery.

[nrnhines]

Issue #513 was handled by pull request #527. However the latter implementation strategy turned out to be too complex to allow reasonable further handling of what was likely to become a significant number of future edge cases. For example, #530. For this reason, #527 was abandoned and pull request branch tobjcount #545, introduced a much more compact and localized strategy to recover the OBJECTTMP stack resources that were leaked in consequence of a hoc_execerror.

The #545 pull request is a substantial improvement in handling hoc_execerrors with the h.method(...) idiom. However there remain further longstanding error recovery issues that can be addressed. For example, if h.method(...) happens to execute a object component sequence po.name or o.o.po.name, etc, where po is a Python Object, and name processing involves a call back into hoc_object_component, and the latter generates a hoc_execerror, then the python resources temporarily created or referenced in the python portion of the name processing will not be destroyed or unreferenced. Clearly hoc_object_component must instead return to python with an error code set so that python can recover its resources, propagate the error up the call stack until we are back in the hoc world, and then the hoc_execerror can be properly completed. Note that significant recursion is not implied as an o.o.po.o.po.o.po.po.o error in any part of the sequence takes place in an execution context in which all previous elements have completed.

Also note that recursion where h.method1(...) calls into python, which then calls the same or another h.method2(...) to any depth, is already handled properly. That is, every h.method(...) sets the hoc 'ocjump' context in which a later hoc_execerror restores the hoc interpreter state to when the 'ocjump' context was set and returns to the python world at the point where python called into the hoc world.