Helper threads for guide
========================

This module may gain from helper threads, and does Vran Calls in some cases.

Threads won't work when output goes to pReflPlot,pReflParam, so we restrict.

guide.c uses a structure NeutronGuide work variable Guide within main.
What is the use of it's entries CriticalAngle and CutoffAngle?
We have to localize Guide to a thread to avoid race usage; to do so we declare
a global variable tguide[MAXWORKER] and use the pointer gW
tguide = TGuide + thread_i;
gW = &(tguide->Wall[0]);
to access values in processNeutron.

The "donkey" routine PathThroughGuideGravOrder1 got the parameter ThisGuide by value - why?
Changed this to "by reference", as for the last parameter RefOut, which will be 0 now
to indicate to do no output, or a valid address else.

The call to 
gsl_ran_dir_3d( vit_gsl_rng, &VX, &VY, &VZ)
  becomes
ran_dir_3d_par(V, thread_i)
Unfortunately the number of calls to ran_dir_3d_par has no principal limit, albeit in praxi
neutrons should not bounce forever in a guide, and the gsl_ran_dir_3d loop will terminate normally
after few rounds due to the randomness of Vran.
So we start with a guess of 100 for mcperneutron, if surfacerough is not 0, and know for sure
we need 0 random numbers else.

CountMessageID: We could synchronize this, or serialize.
Because these calls should be seldom, we use the new debugLock() / debugUnlock()
calls from threadHelper to synchronise.

Other code changes: 
Routines showSetup() and  writeBindata() have been extracted from main.

All free() calls in cleanup routines have been eliminated, there is no need to 
reclaim memory resources if the program itself kicks the bucket.

malloc+memset -> calloc
return;break; in switch -> return
