Add chpl_free_c_string() and use it to clean up leaked c_strings in
string and IO code.
Merge branch 'master' of github.com:chapel-lang/chapel into c_string-leaks
Change the conditional on 's' in chpl_rt_free_c_string() into an
assertion.  This function should only be called from the modules via
chpl_free_c_string() which already employs a null check.
Merge branch 'master' of github.com:chapel-lang/chapel into c_string-leaks
A small rewrite of channel.readstring() to avoid creating intermediate
Chapel strings and also to free intermediate c_strings.

This along with the previous changes reduces the total allocated
memory of regexdna.chpl by about 6% and increases the amount of freed
memory by 96% (which is still less than 10% of the total allocated
memory).
Merge branch 'master' of github.com:chapel-lang/chapel into c_string-leaks
Merge pull request #80 from sungeunchoi/c_string-leaks

Add chpl_free_c_string() and use it to clean up leaked c_string in string and IO code

[reviewed by Greg and David]

This commit adds a Chapel level function called chpl_free_c_string() that frees the c_string argument. For now, the runtime function backing this calls chpl_mem_free(), because I believe all of the non-literal c_strings we use are allocated in the runtime using the chpl_mem_*alloc() functions.  For now it probably doesn't matter, but at some point we should consider replacing these with chpl_here_* functions.

In the modules, various c_strings are now freed. In the String/CString modules, the most significant changes were for c_string concatenation, substring, and casts. In the IO module, functions that returned strings now free their temporary c_strings. In the ChapelIO module, the StringWriter frees its c_string field upon destruction, but due to writePrimitive() replacing 'this', an extra call to string_copy() is needed.

There are still a few places I have not yet removed leaks from, in part due to it being a bit messy (multiple concats) and/or cases where the program is going to exit anyways. I've marked the ones I know of via comments.

Finally, I expect that the string type will eventually support a constructor that takes a c_string argument, so I have marked places in the code where we could use such a call rather than freeing the c_string.

A few testing notes:

- The CString module is now always initialized due to the use of chpl_free_c_string(). Two tests .good files were updated to reflect this (printModuleInitOrder.good and countDeadModules.good)

- During my testing, one of the existing known valgrind errors (modules/standard/gmp/ferguson/gmp_dist_array) failed once even when not using valgrind. I hope this commit does not cause extra noise in nightly testing.

- In memory tracking testing, many string and IO heavy tests saw decreases in memory leaks due to freeing string concatenation and io buffers. The extra string_copy() mentioned above increased total allocated memory for some tests, but no increases in leaked memory were seen for the tests in test/release/examples, test/io, test/types/string.  As an example, the total allocated memory of regexdna.chpl increased by about 6%, but the amount of freed memory increased by 96% (which is still less than 10% of the total allocated memory, but that's another story).