Add 'cray-xc' and 'cray-xe' targets to the 'linux' case.
With locModel=numa and tasks=qthreads, use hwloc's lstopo to create .good.
Get kernel scheduling affinity for the process, not the thread.

Reading a little between the lines of the man page, sched_getaffinity(2)
probably gets the calling thread's scheduling affinity by default, if
you pass 0 (zero) for the pid.  To get the scheduling affinity for the
process you have to pass the process's actual pid.  This makes that
change, with the result that modules/standard/machine/numCores passes
again with locModel=numa and tasks=qthreads.  (It had started breaking
with my https://github.com/chapel-lang/chapel/pull/156, which added the
sched_getaffinity() call to chpl_getNumPUsOnThisNode().)
Adjust comm counts to reflect addition of maxTaskPar member to locale model.
This test case now works as expected, due to #168.
Merge pull request #179 from hildeth/retirePassingFutures

Retire futures that now work due to #168.
Merge pull request #166 from gbtitus/maxTaskPar-fixes

Max task par fixes

[Reviewed by Sung.]

This fixes several failures associated with #156. The specific changes are as follows.

runtime/src/chplsys.c
Fix a failure in modules/standard/machine/numCores: the scheduling affinity used to determine how many PUs there are on the node should be that for the calling process, not the calling pthread.

test/localeModels/gbt/maxTaskPar.prediff
Fix failures in this test: treat cray-xc and cray-xe targets in the same way as linux ones, and use hwloc's lstopo utility to produce the .good file for locModel=numa and tasks=qthreads.

modules/sungeun/init/printInitCommCounts.chpl
Fix a failure in this test: adjust the comm counts to reflect the addition of the maxTaskPar member to the locale model class.