Let insert_new_line_before_closing_brace_in_array_initializer support NEXT_LINE_ON_WRAP

[netomi]

Fixes #5195

What

brace_position_for_array_initializer already supports NEXT_LINE_ON_WRAP for the opening brace: it moves to its own line only if the array initializer's content wraps across multiple lines, staying inline otherwise. The closing brace had no equivalent — insert_new_line_before_closing_brace_in_array_initializer only accepted INSERT/DO_NOT_INSERT, so it was all-or-nothing regardless of whether the content actually wrapped.

This PR adds NEXT_LINE_ON_WRAP as a third accepted value for insert_new_line_before_closing_brace_in_array_initializer, reusing the deferred Token.setNextLineOnWrap() / isNextLineOnWrap() mechanism already used for the opening brace, resolved later by WrapExecutor once wrapping is decided.

Before (with brace_position_for_array_initializer=NEXT_LINE_ON_WRAP, closing brace unconditional):

int[] shortArr = { 1, 2, 3 };

int[] longArr = {
    1111111111,
    2222222222,
    3333333333 };   // stuck to the last element regardless of wrapping

After (with the new value on the closing-brace option too):

int[] shortArr = { 1, 2, 3 };   // unwrapped: unchanged

int[] longArr = {
    1111111111,
    2222222222,
    3333333333
};                               // wrapped: closing brace gets its own line

How

• DefaultCodeFormatterOptions gains a new insert_new_line_before_closing_brace_in_array_initializer_on_wrap boolean field, kept separate from the existing insert_new_line_before_closing_brace_in_array_initializer field so none of the existing call sites that set the old field directly (in FormatterBugsTests/FormatterRegressionTests) need to change.
• LineBreaksPreparator.visit(ArrayInitializer) calls closeBraceToken.setNextLineOnWrap() instead of the unconditional breakBefore() when the new flag is set.
• DefaultCodeFormatterConstants javadoc updated to document the new value.

Testing

Added testIssue5195_shortArrayStaysInline and testIssue5195_wrappedArrayGetsOwnLine to FormatterBugsTests, covering both the unwrapped (no-op) and wrapped (brace gets its own line) cases. I also verified backward compatibility of the existing INSERT/DO_NOT_INSERT values is unaffected — both still produce identical output to before this change.

I wasn't able to run the full Tycho-based test suite in my environment (this repo depends on a sibling eclipse-platform-parent checkout for its build), so I instead verified the formatter behavior directly: compiled the three modified classes against the released 3.43.0 artifacts (org.eclipse.jdt.core, ecj, org.eclipse.jface.text, org.eclipse.text), loaded them ahead of the stock jar via ToolFactory.createCodeFormatter, and confirmed the output for both the wrapped and unwrapped cases matches what's shown above, plus regression-checked the untouched INSERT/DO_NOT_INSERT paths produce byte-identical output to the unpatched formatter. Happy to have a maintainer confirm against the full test suite, and to adjust naming/approach based on review feedback.

---

This PR was drafted with assistance from Claude (Anthropic).