Split chained using statements unless the option is written out

[Mpdreamz]

Closes #89.

using (a) using (b) { } is a sequence, not a nesting: both usings guard the same block and neither is the body of the other. The printer joined the chain onto one line unconditionally, so csharp_preserve_single_line_statements = false was ignored — the bug #89 reports.

Resolving the option would fix that much and leave the larger half wrong. It defaults to true, so a repository with no .editorconfig, or one that never mentions this key, would go on having its usings pulled onto one line. That is a rewrite nobody asked for, and it is not the shape IDE0055 expects.

The rule therefore keys off whether the option was written out at all, rather than off its resolved value:

csharp_preserve_single_line_statements	chained usings
absent	split, one per line
false	split
true	the author's own line breaks are honoured

How

PreserveSingleLineStatementsOption carries the raw setting and PreserveSingleLineStatements resolves it, mirroring the existing KeepExistingLinebreaksOption pair. Only the chained-using rule reads the raw option. Every other behaviour the option governs — a body on its header's line, a catch after a brace, two statements sharing a semicolon, a statement on its case label — reads the resolved value and still defaults to preservation.

Verification

1,210 tests pass. The new cases were checked in both directions rather than only asserted:

• restoring the unconditional join fails the three default-behaviour tests
• an unconditional split fails the opted-in test

Confirmed end to end through curb format on a fixture pair, where the plain directory reports 1 changed and the opted-in directory reports 0 changed.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XK7BnefBydVSaXsrHEavmr