Revise JsonbNumberFormat support

Currently the `@JsonbNumberFormat` annotation supports any NumberFormat that can be specified by a `java.text.NumberFormat`. However, all of the NumberFormats that can be specified in Java are not also valid JSON.

This came up in [this Yasson issue](https://github.com/eclipse-ee4j/yasson/issues/319) where a user pointed out commas are used as the decimal separator in some locales, which is not valid JSON.

See [RFC 7156 section 6](https://tools.ietf.org/html/rfc7159#section-6):
```
6. Numbers

The representation of numbers is similar to that used in most
programming languages. A number is represented in base 10 using
decimal digits. It contains an integer component that may be
prefixed with an optional minus sign, which may be followed by a
fraction part and/or an exponent part. Leading zeros are not
allowed.

A fraction part is a decimal point followed by one or more digits.

An exponent part begins with the letter E in upper or lower case,
which may be followed by a plus or minus sign. The E and optional
sign are followed by one or more digits.

Numeric values that cannot be represented in the grammar below (such
as Infinity and NaN) are not permitted.

number = [ minus ] int [ frac ] [ exp ]

decimal-point = %x2E ; .

digit1-9 = %x31-39 ; 1-9

e = %x65 / %x45 ; e E

exp = e [ minus / plus ] 1*DIGIT

frac = decimal-point 1*DIGIT

int = zero / ( digit1-9 *DIGIT )

minus = %x2D ; -

plus = %x2B ; +

zero = %x30 ; 0
```

### Proposed solution:

Require that implementations impose extra limitations on the patterns that can be specified in a NumberFormat string, namely blocking characters that are not listed in RFC 7159 section 6, such as the comma.

Start with the @JsonbNumberFormat annotation and the JSON number grammar in RFC 7159 section 6. Determine which NumberFormat pattern characters can produce invalid JSON, then verify that unsupported patterns are rejected or constrained; done means formatted numbers remain valid JSON.

Written by the indexing model from the issue text.