Prior to merging this PR, #2504 should be merged.

Closes #686

This PR solves a legacy issue having to do with interpreter calls to density mechanism FUNCTION and PROCEDURE which
make use of RANGE variables. In that case it was necessary to first call h.setdata_suffix(segment) in order to specify which instance of the mechanism range variable data was to be used by the subsequent function call. The problem is that it is understandably the case that the user forgets that h.setdatamust first be called, or that in the potentially extensive interval between the h.setdata call and the subsequent function call, the mechanism instance was destroyed by intervening statements. In either case, a segfault would be generated.

The SOA and Data Handle improvements make it possible to fix this issue, by generating a recoverable error message. This is implemented in the nocmodl translator with the introduction of

static _nrn_non_owning_id_without_container _prop_id{};

to shadow the legacy

static Prop* _extcall_prop;

When the function is called by the interpreter, if _prop_id is not valid, an error message is generated.

The implementation checks whether a FUNCTION or PROCEDURE in fact uses a RANGE variable and, if not, a preliminary call to h.setdata is not required.

POINT_PROCESS behavior of FUNCTION and PROCEDURE is ok since each function call already only uses sec(x).mech.func(args) syntax so that instance is determined at time of the call.

This is most important for HOC users. A subsequent PR (#2475) builds on this for Pyhon to allow something like

soma(0.5).hd.alpl(-65)

which automatically sets the data appropriately. For Python, setdata will never be needed.