Fixing formatDouble scientific notation tests

Rather than having perpetually failing test cases the current Android
behavior has been captured and compared against the Android docs.
The "problem cases" have been merged into one test.

The tests now execute all format() calls and report at the end if any
fail, rather than failing at the first problem. This makes debugging
and comparison easier.

Each output from the affected tests has been inspected. The formatter
settings and some justification have been documented in the tests for
later engineers.

For format() with scientific notation the desired behavior is often
unclear because some parts of the docs contradict others about how
much the min/max integer/fraction values are used.

Many of the "problem cases" were the result of the significant
digit rules not being obeyed by the RI which probably introduced
doubt as to whether Android/ICU was correct.

None of the results were found to be actually wrong, i.e. they appear
to output the input number to the correct amount of precision.

When using min/max integer/fraction digits (i.e. not using '@'
characters), apparently by design DecimalFormat does
not produce strings that make clear the number of significant digits
used to generate them. e.g. 1.0 output to 4 sig digits does not output
1.000E0, but may output 1.0E0 or 1E0 depending on the pattern.

Bug reports have been created to record why some categories of results
are ok or to follow up where behavior is open to interpretation, e.g.
the choice of exponent, or whether leading or trailing zeros are
present in the output.

Bug: 17654561
Bug: 17653864
Bug: 17652647
Bug: 17652196
Bug: 12781028
Change-Id: I6b3944b40ff837ecafd1b1be62c5824edb979930
Fix test_formatToCharacterIterator_original

Two issues fixed:
1) The negative currency cases appear to have never been correct. Almost
certainly they would have had the sign bit as the first element in the
format.
2) The recent change in Android to support the Turkish currency format
broke the TR tests (previously obscured by 1). Bug 16727554 /
commits ef91d1dbd60e9a245b121e3d31c8aad0332a64c7 and
44b0a574cbc3a54e421f5c79020cc59fbd4f34b9.

Bug: 12781028
Change-Id: I6187f7f1feed915b1d8fd5fb398caef7998bfa04
Merge "Fixing formatDouble scientific notation tests"
Merge "Fix test_formatToCharacterIterator_original"
Mark libcore.java.text.DecimalFormatSymbolsTest#test_getInstance_unknown_or_invalid_locale a known failure.

The good news is that for the first time we understand why this is failing.
Too big to fix for L though, and not a regression.

Bug: 17374604

(cherry-picked from commit f887ab7ef74d3ca821aca63ccee2c86cc6a42489)

Change-Id: I589fe2eae0643e07e8db8cbcc7df52563aa24604
Merge "Mark libcore.java.text.DecimalFormatSymbolsTest#test_getInstance_unknown_or_invalid_locale a known failure."
Rewrite tests and add tests that demonstrate a bug

The bug:
DecimalFormat.format() behavior is slightly
lossy around 15 decimal digits even without any
digit constraints.

This change isolates the test failures that result from
this bug to 2 test cases:

test_formatDouble_bug17656132
test_formatDouble_roundingProblemCases

Example of the bug:

Double: 999999999999999.9 is represented as an IEEE 754
value which is exactly decimal 999999999999999.875

When format(999999999999999.9) is called on a DecimalFormat
with large MaxIntegerDigit and MaxFractionDigit....

Correct answer: "999999999999999.9"
Actual answer: "1000000000000000"

By contrast Double.toString() prints 9.999999999999999E14
for Android and the RI (correctly).

The DecimalFormat is printing to 16 decimal digits: The
inclusion of the 16th digit implies slightly more precision
than IEEE 754 provides (~15.9 decimal digits for most of the
representable range).
However, the use of 16 decimal digits for outputting IEEE 754
appears consistent with Double.toString() and elsewhere.

Before printing, DecimalFormat appears to be rounding to
15 decimal digits internally (or something similar).

Parsing "1000000000000000" produces a different double
representation than the original double
(one that is closer to 1000000000000000 than
999999999999999.9). This is the bug - we just lost information.
We should be able to round-trip a double if there is no rounding
since every double is representable with decimal and we have
sufficient digits available to represent it (close enough) in
decimal.

Additional tests have been added to demonstrate the bug
and also demonstrate the (correct) formatting behavior when the
formatter is rounding.

test_formatDouble_maxFractionDigits: rounding at 1, 10, 14 digits
after the dp.
test_formatDouble_roundingTo15Digits: rounding at 15 total digits
overall
test_formatDouble_bug17656132: Demonstrates the bug concisely.

The test changes:

test_formatDouble_wideRange():
implicitly assumed that the any loss of accuracy
when a decimal string was turned into a double
would be undone when format() was called, and it would
always arrive back at the original string. The test
has been re-written here to use BigDecimal rather than
Double.parseDouble(), and to compare two doubles rather
than original string with the output from format().

The test was previously failing with the RI for 1E23:
the closest representable double to 1E23 is exactly
99999999999999991611392.
The value produces "99999999999999990000000" when formatted
with the RI and not "100000000000000000000000". On Android
it was passing for 1E23 because of bug 17656132 rounding
back to the original decimal value.

This test was previously failing on Android with 1E-309 because
below 1E-308 IEEE 754 starts losing precision and the closest
representable value is not close to the original string. The
test now isn't affected if the double being tested is not close
to the original decimal; it passes providing the can be round
tripped.

test_formatDouble_roundingProblemCases: Re-written like the
_wideRange test but continues to demonstrate the bug due to
the test values (intentionally) chosen.

Bug: 17656132
Change-Id: I7d81e38bd1f9dbfd1e1b2caa60a6bb16b871b925
Merge "Rewrite tests and add tests that demonstrate a bug"