<i18n dev> RFR: 8333396: Performance regression of new DecimalFormat and DecimalFormat.format

[lingjun-cg]

### Performance regression of DecimalFormat.format
>From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
So I added support for some new methods that accept StringBuilder which is lock-free.

### Performance regression of new DecimalFormat
After comparing the flame graph between current jdk and jdk 11,  the method java.text.DecimalFormatSymbols#findNonFormatChar takes a significant time.  The performance becomes as good as jdk11 after replacing it with a simple loop implementation.

-------------

Commit messages:
 - 8333396: Performance regression of new DecimalFormat and DecimalFormat.format

Changes: https://git.openjdk.org/jdk/pull/19513/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333396
  Stats: 318 lines in 11 files changed: 268 ins; 0 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/19513.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513

PR: https://git.openjdk.org/jdk/pull/19513