Fix passing sync/single variables by ref/blank intent.
Followed up on reviewers' comments.
Added tests. Retired a future.
Added another isX test; strengthened type-tests.chpl.
type-tests.todo.chpl is now covered by type-tests.chpl,
so I removed it.
More test adjustments.
Also allowed sync/singles in tuple *types*
- see parallel/sync/diten/tupleOfSync.chpl
Followed up on the second round of Brad's comments.

Two TODOs:
* [ ] David's review of test/modules/diten/moduleNotInitialized.chpl
* [ ] why passing sync/single by reference is specific to ref/blank intents?
Followed up on Brad's latest comments and group discussion.
* writeThis() is a compile-time error on sync/single
* corresponding test changes - added readFE/readFF when writing
* moved max() error testing from error-min-on-syncs.chpl into separate file
* adjusted an error message to say 'currently'
More test updates - add readFE/readFF when writing sync/single.

I used readFF() on a sync, instead of readFE, in a few cases
where the computation is over, to say ''read the value and
keep it there just in case''.

I also slightly updated the sync/single primer with sync/single
generic formals, mention we can't just write them, added
some clearly missing newlines.
Updated the error messages, after consulting with Brad.
Adjusted the comments on sync/single .writeThis().
Avoid fleeting line numbers in .good
Merge pull request #420 from vasslitvinov/sync-vars-pass-by-ref

Fix passing sync/single variables by ref/blank intent.
Disallow passing sync/single/atomic variables to min()/max().
Disallow passing sync/single variables to write() and associated functions
that come down to calling sync/single.writeThis().
Disallow storing a sync or single variable into a tuple.

When a sync or single variable is passed as an argument to a generic formal
by blank intent or [const] ref intent, pass it by reference.
The generic formal is instantiated to the actual's type.

While there, I removed the flag FLAG_NO_SYNC_DEMOTION from the compiler
and the corresponding pragma from the module files. In my earlier test
runs, comm=none and gasnet, even independent of the other changes in
this merge, the compiler never comes across anything with this flag
set. So I am taking it out altogether.


IMPLEMENTATION NOTES

The implementation of passing by reference/the first paragraph above
turned out to be simple - I added 4 lines to generics.cpp.

Disallowing things listed above was also simple. The first two checks
are straightforward in the modules.

The third check was motivated by an extraneous dealloc of the sync
variable that got inserted because it was stored in a tuple, in this
test prior to this merge:
  release/examples/spec/Task_Parallelism_and_Synchronization/syncMethods
see DETAILS below.

I did not take up fixing that, instead disallowed the idiom.
This is done using checkForStoringIntoTuple() in functionResolution.cpp.  
I had to ignore certain _build_tuple calls because our existing code
base uses it. E.g. *declaring* a tuple with a sync var component is OK:
  parallel/sync/diten/tupleOfSync.chpl


DESIGN

* We had been longing for a while to have syncs be passed by reference
to generic formals. See e.g. test/functions/vass/sync-by-ref.chpl.
Instead syncs had been readFE()-ed in these cases.


* However we did not realize that we actually had relied on the implicit
readFE() when passing syncs to min()/max() and write() et al. -
which all are generic in their arguments. This change resulted in
eliminating the outter readFE() in these cases and moving it
inside min()/max() and in sync/single.writeThis() that I had to create.

Neither worked - see DETAILS below.

In a group discussion we preferred to raise an error in these cases.
Otherwise users will subconciously make assumptions about how it works,
and the assumptions may end up being incorrect and result in deadlocks.

However we are open to hearing suggestions from users about how to
handle these cases, in particular what to do when writing a sync/single.

E.g. we considered having write(sync/single) just show their state
(full or empty + the value), ignoring whether it is full.

See also the email thread that Brad started today, re:
  Change to sync/single write*() interpretation (and min/max)


* If a record (or a class, too?) has a sync or single field,
that record needs to define writeThis(). Otherwise writing out
that record will result in a compile-time error. See:
  test/types/single/sungeun/writeRecordOutProc.chpl

We may reconsider some of our design in this light.


* Going forward, we would like to store syncs, atomics, arrays,
etc. in a tuple *by reference*. That will be consistent.

Also, have the generic formal take the type of the sync/single
actual argument for the other intents as well, not just blank
or ref.

Would be great to unify this with the behavior of atomic types.
However the atomics are significantly different from sync/singles,
at least in our minds.


OTHER

* To deal with these changes, I modified quite a few tests,
typically by inserting readFE() and readFF().

I applied to readFF() even to sync variables in several cases,
when it did not change the observable behavior. Mostly this was
when the variable was read out at the end of the test, after
the computation that required sync-ness had finished. My mental
model in those cases is "keep the variable available in case
somebody else will want to read out its value later."


* Happily, this change fixes the remaining bugs in the isXxx functions
from PR #212.

I retired a future and added more testing. The now-working test
type-tests.todo.chpl is mostly superceded by
isX.byBlankArgs-compWarns.chpl, so I removed it.  The test
type-tests.chpl is mostly superceded by isX.module-writeln.chpl.
I kept it because it has a couple of twists that the latter doesn't.


* I updated slightly the sync/single primer, to talk about sync/single
generic formals. I mention we can't just write them. Also I added some
newlines that were needed IMO.


SOME DETAILS

* Putting a single variable in a tuple would now result in an extra
deallocation of that single variable, e.g. at close-brace here:

  // from spec/Task_Parallelism_and_Synchronization.tex - syncMethods.chpl
  {
    var x$: single int = 1;
    writeln((x$, 1));
  }

This is new due to _build_tuple taking that single variable by
reference. I wonder if it's easy to fix by throwing some flag
"do not deallocate" on the single var?
For now, we generate a compiler error for this.


* To make write(x$) write the base variable preserving the behavior
prior to this change, the most natural place would be to add

  //  modules/internal/ChapelSyncvar.chpl
  proc _syncvar.writeThis(x: Writer) { x.write(this.readFE()); }
  proc _singlevar.writeThis(x: Writer) { x.write(this.readFF()); }

However, the effect of this is that the sync var's lock is sought
*after* locking the channel that's being written to.

Indeed, the call write(x$) progresses as follows:

  channel.write(args ...?k):bool
  channel.write(args ...?k, out error:syserr):bool  <--- IO.chpl:1991
  _write_one_internal(_channel_internal:qio_channel_ptr_t, param kind:iokind, x:?t)
  Writer.write(args ...?k)
  Writer.writeIt(x:?t)
  _syncvar.writeThis(x: Writer)

The channel gets locked in channel.write/IO.chpl:1991.
The sync var readFE() only happens in writeThis, when the channel
is already locked.

Therefore the following code is an unintuitive deadlock, which
it wasn't before:

  var x$: sync int;

  cobegin {
    { writeln(x$); }
    { sleep(1);
      writeln("about to assign x$");
      x$ = 1;  }
  }

The first writeln() is stuck on x$; the second writeln() is stuck
on the channel lock that the first one is holding.


* If we leave min()/max() unchanged and and allow passing sync vars to them:

  proc min(x, y) return if x < y then x else y;

If the 'then' branch is taken and x's actual is a sync variable, it
would get read twice, which is not intuitive and will likely dead-lock.


Reviewed and contributed to by Brad and somewhat by Tom.