Fix two parse issues related to newlines

[maksbotan]

Bugs fixed

When the Data (records) step reformatted declarations containing long type signatures or deriving via clauses with gap strings, the GHC pretty-printer (showPpr) could insert newline characters into rendered type expressions. These newlines ended up embedded inside single Lines entries rather than being split into separate lines. Subsequent steps--most notably simple_align--would then miscount line numbers, causing them to modify the wrong source lines and corrupt identifiers elsewhere in the file (e.g. garbling variable names in unrelated record fields).

The bug manifested in two scenarios:

1. Long record field types -- showPpr would line-wrap types like M.Map (Name, SomeLongKeyType, AnotherVeryLongKeyName) SomeVeryLongResultType, injecting \n into the output of the Data step.
2. deriving via with gap strings -- Haskell gap strings ("foo\<newline> \bar") contain literal newlines that passed through showOutputable and into Lines entries unsplit.

In both scenarios, stylish-haskell failed with parser error instead of producing any results.

Summary

• Fix showOutputable to avoid inserting newlines: Replace GHC.showPpr (which uses the pretty-printer's line-wrapping logic) with GHC.showSDocOneLine so that rendered types are always single-line strings. This prevents the Data step from producing Lines entries containing embedded \n characters.

• Handle embedded newlines in Printer.putText: Make putText split on \n and emit proper newline calls, so that even if a GHC pretty-printed string contains newlines (e.g. gap strings in deriving via clauses), the resulting Lines are correctly segmented. This prevents subsequent steps (like simple_align) from miscounting line numbers and corrupting identifiers.

• Add regression tests: Two integration tests (case01, case02) in Regressions.hs that exercise the full records -> simple_align -> trailing_whitespace pipeline on inputs that previously triggered the bug -- records with long types that showPpr would wrap, and deriving via clauses with gap strings.

Disclaimer

Idea of the fix was produced by claude opus 4.6 and later polished by myself. Suggestions how to improve this PR are more than welcome.