Fix memory leak when using DateTimePatternGenerator

Instance created by DateTimePatternGenerator::createInstance() needs to
be deleted

Change-Id: I3e6058f717e56dbc06ffaca35ff6ae06059b689d
Signed-off-by: Carton He <carton.he@marvell.com>
Reduce the upper bound on TimeZoneNames memory usage.

The cache had mistakenly been sized based on the number of time zones,
despite the fact that the keys are locales. We now have a lot of locales,
but the cache was still large enough to hold all of them, which wasn't
really the intent. I pulled the number 5 out of my ass.

I've also removed the "one big intern table" and now just do per-locale
deduplication. That avoids another potentially very large leak in an
ill-behaved program.

Also handle OOME in the native code better.

Change-Id: I9a07ad210469f064acde80f7d10ffb4b3a8f6443
Fix BIO_OutputStream::write to return the correct length.

This was leaving bad OpenSSL error states lying around for later
innocent calls to trip over.

Also clean up some of the other error reporting/handling.

Bug: 9822466
Bug: 10344304
Change-Id: I9e6d6fd9a6c5e466336217b47f45c211aff5555d
Fix German date parsing.

CLDR changed German from having a mix of 3- and 4-character abbreviated month
names (such as "Juli" and "Aug"[ust]) to having only 4-character names by
adding periods to the end of abbreviated names (giving "Juli" and "Aug.").
This means that a date formatted with the old data (by jb-mr1, say) can't
be parsed with the new data (in jb-mr2, say). Work around this by doing what
icu4c's SimpleDateFormat::parse does --- accepting "xxx" as a match for "xxx.".

Bug: https://code.google.com/p/android/issues/detail?id=59383
Bug: 10511599
Change-Id: I021ea8ffeea37ea2cae943a84cdd2babb337301d