changed tiny 'bug', runtime.GOMAXPROCS now uses command line '-proces=value'

I was interested by your article. When I read the Go lang source, I noticed that the `-procs=value` command line argument was partly ignored. The `*procs` value was used to set the number of 'search' goroutines, but was not used to set `runtime.GOMAXPROCS`. Instead the number of GOMAXPROCS goroutines was hard-wired to `runtime.GOMAXPROCS(runtime.NumCPU() * 2)`. This has the effect of allowing 2x more GOMAXPROCS goroutines than 'search' goroutines by default, which did not seem quite right. 

This seemed like a bug for a test of concurrency or parallelism. So I changed it. 

To be fair, it feels like the value of `GOMAXPROCS` and the number of 'search' goroutines might be best set independently, however I tried to minimise my impact on your code. I might instead set the 'multiplier' in the `runtime.GOMAXPROCS(runtime.NumCPU() * multiplier)` statement.

In the change, the default `*procs` value is now `runtime.NumCPU() * 2`. Hence the program's default GOMAXPROCS is the same when `-procs` is *not* used on the command line. 

An implication of the change is the program now uses `-procs=value` to set the number of `Spawn(...)` goroutines, which *is* different. I assume the vast majority of run-time is used by the searching goroutines, so this seemed a reasonable choice, but it is a change of behaviour. The alternative, to set `GOMAXPROCS` to 2x more than the number of search goroutines, made less sense to me but would have preserved the original behaviour.

I've run the program for `-procs=1`, `-procs=4` and `-procs=8`; the (sorted) output is the same as the original. The runtime is, of course, different, with `-procs=1` real and user time being close, as I would expect.

I hope this might be useful. However, I can understand that I may have got the wrong idea, and the program works the way you wanted it to.