ICU-20392 Split the Locale payload into nested and heap allocated.

All the most commonly used Locale objects have very little payload, most
of them don't use any extensions, don't use a language tag longer than 3
characters and don't use more than a single variant.

There's room for all that data in a simple 32 byte large payload object,
which can be nested directly in the Locale object.

Any payload larger than that can instead be heap allocated as needed, in
order to save storage for the most commonly used objects while retaining
the ability to create arbitrarily large and complex Locale objects.

This reduces the storage requirements for all Locale objects.

For nested payloads, this reduction is from 224 bytes to 48 bytes.

For payloads that need to be heap allocated, the reduction depends on
several factors, but for most cases there's some reduction. There are
also cases where this refactoring actually increases the storage used,
because CharString allocates more storage than necessary. There are a
number of ways in which this could be improved upon, such as optimizing
CharString to not allocate more than necessary when copying a string of
known length, not allocating any empty CharString objects or possibly
replacing CharString with a new class for fixed length strings.

The public API remains unchanged but the operations which can lead to
U_MEMORY_ALLOCATION_ERROR change.

Author: roubert