Don't use StaticString.utf8Start unless there is a pointer rep.

[thomasvl]

The docs for StaticString.utf8Start say it should runtime abort for this, so
play it safe and handling when a StaticString doesn't have a ptr rep.

[thomasvl]

@tbkka - @allevato noticed this when we were looking at the two issues that came in, it seems like this is the right thing to do to ensure things always work.

No clue if it is related to the two issues…

[tbkka]

I'm fine with the approach proposed here for working around the current concern, but I suspect this code can be radically simplified. A lot of the complexity here was motivated by issues with the original UTF-16 Swift String implementation, but things are very different now. For example, we can likely just drop the utf8Buffer property entirely (and all of the tedious interning) if we just pre-compute and store the hash value so that we can rapidly compare with identifiers in JSON or TextFormat input. Careful benchmarking is certainly warranted, but it's entirely possible that a more straightforward approach built on the standard String type would actually be faster than this code.

[thomasvl]

Yea, the whole parsing/serialization pipeline likely could get a revalidation due to the String changes, there might be a few places things can be streamlined.