Add chpl_free_c_string() and use it to clean up leaked c_string in string and IO code

@daviditen

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.

@gbtitus: Will we want to eventually better distinguish when we should be using chpl_here_* with c_string?

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 it's 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 test, but no increases in leaked memory.