Reduce c_string_copy concatenation leaks

Another c_string_copy cleanup task.

Because there was no distinction between owned versus unowned c_strings, most owned c_strings (now c_string_copy) return values were dropped on the floor, especially in chained concatenation.  By creating special versions of concatenation (+) taking a c_string_copy in one or both args, these formerly leaked c_string_copies can be consumed and freed.

This patch would have been a lot smaller without the (recently added) Chapel language restriction against binding a plain (lvalue) ref argument to an temporary.  This forces the programmer to name any such temporary, which leads to a very stilted and hard-to-read programming style (IMO).  This PR also points out that changing an argument from pass-by-value to pass-by-reference affects the source code, even if the client code is unaffected semantically.  (In this case, the only visible change is that the client code leaks less memory.)

@vasslitvinov may consider this pull request "interesting".  I only changed the interface of concatenation taking a c_string as its other operand, which means that the versions taking a Chapel string still leak.  I'll wait for feedback on this initial patch before proceeding with that modification.