[racket] Better discoverability for errortrace

Small comment: In addition to discoverability, try to have this go 
direct to *understanding* of how&when to use "errortrace".

(Multiple times over the years, I have been doing crucial performance 
optimizations to server code, and remnants of various versions of 
"errortrace" kept getting added back into the code. Pattern: get it 
optimized, incidentally also remove killer "errortrace" bits, then 
someone merges the changes, and some terrible "#! ... -l errortrace" or  
ancient "require ... errortrace.ss" somehow sneaks back into several 
different places each in multiple branches, sneaks back into hurting 
production capacity.  Even if you provide a switch in the app-specific 
build environment to enable/disable errortrace.  With lots of code and 
lots of branches and merging, it seems that errortrace can be like bed 
bugs -- terrorizing you with small bites everywhere, and you just can't 
get rid of it.  This might seem like a CM and merging problem, not an 
"errortrace" problem, but it seems somewhat peculiar to "errortrace" in 
practice.  I am forming a theory that some programmers are afraid to let 
a merge remove whatever cargo-cult incantations they found in the past 
gave them better backtraces, damn any consequences. :)  Hence my 
suggestion to have your improved discoverability send the programmer 
direct to *understanding*, rather than to cargo-cult "add this magical 
snippet to your project" with an implied "and never lose the faith".)

(Like many programming pragmatics, I know it looks silly to consider 
this seemingly little thing a matter of importance worth mention, but my 
view from the ground is that it has been important.)

Neil V.