Turn off work stealing for qthreads

[ok'd by greg and sung]

We have been having some performance regressions with qthreads. Using chameneos
as a case study, it appears that a significant amount of time is spent in the
work stealing routines, especially when the number of tasks < number of
qthreads workers.

This initial commit is to see the performance results of this and any testing
fallout. If this seems to resolve them, we can decide if this is a good default
and if there's cases it shouldn't be the default such as NUMA. We can also
provide a mechanism (execution config and/or function) to allow users to turn
on work stealing if their problem requires load balancing.


Also reverting chap03 to use the default sherwood scheduler again. We were
trying out nemesis because it didn't have work stealing and that seemed to
resolve our performance regressions there. If there are performance hits on
chap03 because of this that means there is additional overhead of using a
scheduler that supports multi-threaded shepherds (default sherwood) vs one that
only supports single-threaded shepherds (like nemesis.)


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@23779 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Add docs with information about git workflow, setup, and git cheat sheet.

The new documents use ReStructured Text markup. This is a forward looking
switch so we can one day publish this type of documentation in html form on the
web.

r: @bradcray

git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@23780 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Remove subversion related bestPractices/ docs.

r: @bradcray

git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@23781 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Skip RBC benchmark for valgrind testing.

Execution is timing out and it is not clear/simple to reduce the problem size.

Discussed with @vasslitvinov

git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@23782 3a8e244f-b0f2-452b-bcba-4c88e055c3ca