Add runtime support for the upcoming string implementation.

runtime/include/chpl-mem-desc.h:
  Add new memory descriptor types STRING_INIT_DATA and STRING_COPY_REMOTE.

runtime/include/chpl-string.h
runtime/src/chpl-string.c:
  Add new support functions.

  - initString() takes 2 strings, old and new.  If old is longer than
    new, it copies new into old and returns old.  Otherwise, it frees
    old and allocates space for a copy of new.  I'm not crazy about
    this name, so any suggestions are welcome.

  - remoteStringCopy() takes a remote node id, remote address, and
    string length.  It allocates space for the remote string and
    copies the string from the remote locale.

runtime/src/chpl-string-support.c:
  Removed incorrect comments regarding the use of the string literal "".
Merge branch 'master' of github.com:chapel-lang/chapel into record-string
Rename and change functionality of runtime function for allocating a local string.

I never liked the name initString, but I found a better name for it
due to restructuring the functionality.  It's now called stringMove(),
which copies the len bytes of src into dest and returns dest.  If dest
is "", then it allocates a new buffer for the copy, and returns that
buffer.  It is the caller's responsibility to make sure the src is
large enough to hold dest.

This puts the buffer reuse policy into the new string module.  Note
that the allocation must be done in the runtime since there is no way
to call chpl_here_alloc() from the runtime.
Updating comment on stringMove().
New string record.
Merge branch 'master' of github.com:chapel-lang/chapel into record-string
New string implementation and memory leaks tests.
Merge pull request #310 from sungeunchoi/record-string

Strings as records implementation

[reviewed by @daviditen]

This commit includes a new module called `NewString` that implements a reference counted string type using a record. These new strings, currently called `string_rec`, are designed to be a drop-in replacement for the current Chapel strings, though much work in the compiler and runtime will be needed to make them so (mostly ripping stuff out). For the most part, the original string interface was maintained, but it was decided to stop supporting `toString` and `_string_contains`. `NewString` requires 2 new runtime functions and 2 new memory allocation descriptors.

The actual string data is backed by a `baseType` which is currently `c_string`. The `baseType` is required to provide the `c_string` interface as well as a couple of functions for copying. The base string is assumed to be a local-only type like `c_string` for memory management purposes, so user strings of `baseType` will never be copied to a remote locale, though internal `baseType` strings can be copied. For the most part, the user should never use `baseType` strings, a notable exception being the IO module.

I chose to support a few operations between `string_rec` and `baseType` like concatenation and assignment, since they are commonly used. In other cases, a `baseType` string must be cast to `string_rec`. When this becomes the default string implementation, the compiler will coerce `c_string` to string as it does now. If the `baseType` is replaced, this coercion will not happen automatically.

This commit also includes a suite of tests designed primarily to check for memory leaks of string implementations. It contains unit tests for all the string operations, checking for both single and multilocale memory leaks. Currently, there are no memory leaks. There is a config type called `string_impl` that is used to define the string implementation, currently `string_rec`. When this implementation becomes the default Chapel string implementation, `string_impl` can be changed to `string`. Obviously, if others choose to implement their own strings, they can set `string_impl` to test their new strings. It is my hope that this suite will grow to include stuff from the new Strings library as well as performance tests.