Initial commit to try and get rid of qthread deadlock

There are a couple of tests that deadlock with qthreads now that the nemesis
scheduler is the default. They are tests where the main task is in a loop
waiting for a sync var to have a certain value and other tasks are being
created inside the while loop to increment the sync var. Some of the tasks
getting created never get to run because the main task never yields and thus
the main loop is waiting for tasks that it's not letting run to update a value.
To remedy this the plan is to do a qthread_yield every x unlocks for any given
sync var. This does a qthread_yield every 1024 iterations. I tried with 32 and
256 and they both seemed to yield too often through the non-scientific method
of putting some prints when we yield and seeing how often we yield for a few
test programs and also checking how long they take to finish into account.
Improved constness checking on fields; adjusted Chapel code.
Update to how often qthreads yields for sync var unlock

This moves the check to use the return value of qthreads_incr, which means we
get the previous value of lockers_out but we get rid of a race.

The previous code was something like if (lockers_out & 0xFF) then yield but you
want if ((lockers_out &0xFF) == 0) since the other way yields for all but the
one iteration. Finally, this bumps up the number of unlocks before yielding.
This is based on trials with test/domains/sungeun/assoc/stress.numthr.chpl .
No stack checks, and smaller stack for domains/sungeun/assoc/stress.numthr.chpl

For qthreads this test was running out of memory because there were too many
tasks existing at the same time. This was especially a problem with 8M stacks
so this lowers that to 128 and turns of guard pages to reduce memory usage and
because this test creates a lot of tasks. I believe this wasn't an issue for
fifo because there is a limited number of pthreads (and thus stacks) that can
exist, whereas qthreads imposes no such limit.
Don't yield for first unlock of sync var for qthreads sync var unlock

Previously yield for if ((lockers_out % 4096) == 0) meant we would yield on the
first unlock. This just changes it to if ((lockers_out % 4096) == 4095) so that
we still yield after the same number of iterations but the first yield is moved
back to the 4095 unlock instead of the first.
Lower how many iterations until we yield
Merge pull request #159 from ronawho/qthreads-syncvar-deadlock

Do a qthread_yield() after X number of unlocks on a sync variable

Note: This idea was ok'd and comes from greg and sung. This exact patch hasn't
been reviewed, but it passed full testing and I want to see the performance
results so that we can setup something for good testing over the weekend and
hopefully switch to qthreads as default after the weekend. After seeing the
performance and correctness results I'll update the patch and have it formally
reviewed.

After switching to the nemesis scheduler as the default scheduler for qthreads
we had 5 deadlocks essentially coming from 2 tests:
test/domains/sungeun/assoc/stress.chpl and test/users/shetag/fock/fock-1.chpl.

In these tests the main task is waiting for a sync var to have a certain value
while other tasks are incrementing that sync var. In this case some tasks that
are adding to the sync var are put on to run on the same worker as the main
task. The main task is never yielding and thus it keeps waiting for a sync var
to have a value that it is preventing from getting updated.

To remedy this, we now yield after 256 unlocks of any given sync var. The
specific number has come from some trial and error with the previous tests and
will probably change after some more trial and error and looking through
performance results.

This also lowers the stack size for a test that creates an enormous amount of
threads and turns off guard pages to avoid running out of memory.
Minor changes to follow up on Tom's review
Merge pull request #157 from vasslitvinov/improve-const-field-checking

Improved constness checking on fields; adjusted Chapel code.


COMPILER CHANGES

functionResolution.cpp
wrappers.cpp

* Improved the logic of const checking added in SVN r22963.

** Check field accesses on result of *any* function with FLAG_REF_TO_CONST,
   not just field accessors.

** Check field accesses also to const formals, e.g. blank-intent records.

   For that, I replaced the check:  baseSym->hasFlag(FLAG_CONST)
   with:                            baseSym->isConstant()

** Propagate FLAG_FIELD_ACCESSOR and FLAG_REF_TO_CONST
   to wrappers.

* Factored out some const-checking code in resolveNormalCall()
  into a separate setFlagsForConstAccess().

* For now, promotion wrappers are not checked, due to scheduling concerns.
  There is a corresponding 'if' condition in setFlagsForConstAccess().
  This might produce incorrect errors in some cases, not exercised
  in our current code base.


MODULE CHANGES

* Switched the field locale.numCores to be 'var' (from 'const').
  That's because it is modified in RootLocale.init(), which
  is invoked outside of a constructor - in chpl_init_rootLocale().
  This was Sung's suggestion, making us forward-looking to having
  a node's core count adjustable at run time.

     modules/internal/ChapelLocale.chpl

* range.member no longer modifies its arguments. For that, I added a
  helper function that takes one of the arguments by 'in' intent, to
  indicate an explicit copy.

  I did not make the arguments of range.member themselves have 'in' intent,
  assuming that in many cases they will be passed by reference (blank
  intent), so copies will not be made.

     modules/internal/ChapelRange.chpl

* Changed several formals of the type 'qio_regexp_t'
  from 'ref' to 'const ref':

     modules/standard/Regexp.chpl
       qio_regexp_retain
       qio_regexp_get_options
       qio_regexp_get_pattern
       qio_regexp_get_ncaptures
       qio_regexp_ok
       qio_regexp_error

     modules/standard/IO.chpl
       qio_regexp_channel_match

  Correspondingly, in the runtime C code, changed
  qio_regexp_t* regexp  -->  const qio_regexp_t* regexp

     runtime/include/qio/qio_regexp.h
     runtime/src/qio/regexp/re2/re2-interface.cc
     runtime/src/qio/regexp/none/fail-regexp.c

  To motivate, consider for example proc =(ref ret:regexp, x:regexp)

    - It takes 'x' by blank intent. 'regexp' being a record,
      this means that 'x' is constant and it is illegal
      to modify its fields.

    - It passes x._regexp to qio_regexp_retain() by 'ref',
      which is considered to be a modification, and so is illegal.

  If we want at all to allow assignment from a "const" regexp,
  we want the above process to be read-only for 'x'. Therefore
  we want qio_regexp_retain() to be read-only as well.

  Another solution is to make a copy on the fly and modify that one.
  However, given that the modification is related to reference counting,
  that would not make sense.

  I consulted with Michael on the above and he expressed a preference
  not to bake constness into the interface. However he has not,
  as of this writing, offered an alternative solution.

* Replaced the blank-intent 'style' formal with 'in local_style',
  to indicate an explicit copy for local modifications, in:

     modules/standard/IO.chpl
       channel.channel()
       file.lines()

  Correspondingly, removed one 'local_style' variable.


TEST CHANGES

* range.member no longer modifies its argument

     test/arrays/vass/slices-with-negative-strides-1.good

* specify 'ref' task intent so the variable can be modified in a 'begin'

     test/parallel/begin/waynew/record1.chpl
     test/parallel/begin/waynew/record2.chpl

* pass a record by 'in' to allow local modifications;
  it looks like the actual better remains unmodified

     test/studies/hpcc/HPL/marybeth/HPL.chpl

* blank-intent record formals no longer allow field modification,
  so this future is removed

     test/types/records/const-checking/todo-assign-to-record-formal-error.future