fix: preserve leading newline of multiline string built with string()

[Sanjays2402]

Problem

tomlkit.string(value, multiline=True) produces output that silently loses a leading newline on round-trip.

>>> import tomlkit
>>> s = tomlkit.string("\nfoo", multiline=True)
>>> str(s)                 # the String value is correct
'\nfoo'
>>> s.as_string()          # ...but its serialized form is not
'"""\nfoo"""'
>>> str(tomlkit.parse(f'k = {s.as_string()}\n')["k"])
'foo'                      # <- leading newline dropped!

Per the TOML spec: "A newline immediately following the opening delimiter will be trimmed." So """\nfoo""" decodes to foo, not \nfoo. The String object reports the right value, but its rendered form is wrong, so the data loss only appears after the output is parsed again.

This is a genuine serialization bug, not a TOML 1.0 vs 1.1 difference — both tomllib (1.0.0) and tomlkit's own parser (1.1.0) decode the old output to the wrong value:

string(value, multiline=True).as_string()	reparses to (before)	reparses to (after)
"\n" → """\n"""	"" ❌	"\n" ✅
"\nabc" → """\nabc"""	"abc" ❌	"\nabc" ✅
"\r\nx" → """\r\nx"""	"x" ❌	"\r\nx" ✅
"abc\n" → """abc\n"""	"abc\n" ✅ (unchanged)	"abc\n" ✅

Affects both basic (""") and literal (''') multiline strings, and values starting with \r\n.

Root cause

In String.from_raw (tomlkit/items.py), the rendered body is placed directly between the delimiters. For a multiline type, \n/\r are intentionally kept literal (not escaped) for readability — but nothing accounts for the parser's rule that trims the first newline after the opening delimiter, so a body beginning with a newline is one newline short after re-parsing.

Fix

When the string is multiline and its rendered body begins with a newline, emit an extra leading newline — the one the parser trims — so the intended value survives the round-trip. This is exactly the representation the spec prescribes for such values. Single-line strings and multiline strings that don't start with a newline are unchanged (surgical, +7 lines).

Tests

• An existing test_create_string case asserted the old lossy output ("""\nMy\nString\n"""). It only checked as_string(), never a round-trip, so it had locked in the bug. Updated it to the correct, round-trippable rendering.
• Added test_create_multiline_string_with_leading_newline_round_trips, covering basic/literal multiline and \r\n-leading values, asserting parse(render(v)) == v.

Proof the regression test guards the fix (source change stashed, tests kept):

# without the source fix:
6 failed, 32 passed        # 5 new round-trip cases + the corrected case
# with the fix restored:
38 passed

Full suite: 1040 passed (was 1035), ruff check clean, ruff format --check clean on changed files.