[#835] [V70001] [GTM-9410] Fix longstanding spinloop in GDE error trap exposed by v70001/gtm9410 subtest

• While implementing YDBTest!1814 (merged) (YDBTest@c6eec83e), I tested a use case where multiple GDE processes are invoked and try to modify the mumps.gld file at the same time. In some test runs, I noticed that the GDE processes were in a spin loop and never exiting.

• Turns out they were trying to CLOSE the file mumps.gldinprogress. And encountering a %SYSTEM-E-ENO2 error because that file did not exist (due to a concurrent GDE process removing it).

• The error trap in sr_unix/gdeput.m set up a device exception handler (gdexcept variable) when opening the device tempfile. But the writeerr entryref (which is what gdexcept invokes) did not take into account that tempfile could not exist. And because of this, the CLOSE command would encounter a runtime error that in turn would go back to the device exception handler which in turn would invoke writeerr^%GDEPUT and encounter the very same error again and so on.

• The fix is simple and is to check if the file tempfile exists (using $zsearch) and only in that case invoke the CLOSE command. This avoids the indefinite device exception handler invocation.