MemoryBuffer has poor type safety

Back in ea5a137e558f36602616268ede35dcfeb92aa3e3 `MemoryBuffer` was overloaded to be *sometimes* null-terminated. Since then a number of conversion functions were added that further muddy the waters and make it difficult to reason about whether the null terminator is present or not (e.g. conversion to and from `MemoryBufferRef` which is backed by `StringRef`, which is explicitly not null-terminated).

Removing null termination is not an option - various parsers rely on the null terminator as an optimization. This also means that constructing `MemoryBuffer` for use with parsers is fragile: if the buffer contains an interior null byte, parsing will end earlier than the caller expects.

Type safety can be improved by splitting this type into two: one null terminated, one not. The null terminated type should take the full length at construction (including the null terminator) and check that there aren't any interior null bytes.

The issue names MemoryBuffer, MemoryBufferRef, StringRef, and parser use; start by tracing their definitions, conversions, and parser call sites. The work is done when null-terminated and non-null-terminated buffers are distinct, construction includes the terminator in the full length, and interior null bytes are rejected.

Written by the indexing model from the issue text.