String literals with embedded newlines gain indentation on every format pass

[gmr]

Summary

A string literal containing an embedded newline gains a space of indentation
every time the statement is formatted, so format() is not a fixed point and
the literal's value drifts on each pass.

This changes data, not just layout: the extra spaces land inside the string
constant.

Reproduction

SELECT js FROM (VALUES ('[{"a":"1"},
 {"b":"2","b":"3"}]')) foo(js);

Formatting repeatedly with Style::River:

pass 1   ... (VALUES ('[{"a":"1"},
                {"b":"2","b":"3"}]')) AS foo(js);
pass 2   ... (VALUES ('[{"a":"1"},
                 {"b":"2","b":"3"}]')) AS foo(js);
pass 3   ... (VALUES ('[{"a":"1"},
                  {"b":"2","b":"3"}]')) AS foo(js);

One space is added per pass, and the value of the JSON string changes each
time.

Cause

Continuation lines of multi-line content are re-indented to the content column.
A newline inside a string literal is data rather than layout, so the line that
follows it must be left exactly as written.

#56 fixed this in river_line by skipping lines whose preceding newline falls
inside a literal (newlines_inside_literal in src/formatter/select.rs). At
least one other path still re-indents — the drift shrinks from several spaces
per pass to one, but does not stop. The remaining path is somewhere between
format_values_clause and the subquery/table-ref rendering that wraps it.

Suggested approach

The quote-aware check added in #56 is reusable; the remaining call site needs
the same treatment. A broader fix would be to make the indenting helpers take
the literal-awareness into account once, rather than at each call site.

Test

tests/reparse_test.rs::formatting_is_idempotent_in_every_style currently skips
this statement:

if sql.contains("array w. UK?") {
    continue;
}

Removing that skip should be part of the fix.

[gmr]

Same defect, second path: function bodies. A dollar-quoted body is a string constant too, and reindent_body() (src/formatter/stmt.rs) rewrites it for every language: it strips the lines' common indentation and adds one space.

CREATE FUNCTION pymax(a integer, b integer) RETURNS integer AS $$
if a > b:
    return a
return b
$$ LANGUAGE plpython3u;
-- body comes out as
 if a > b:
     return a
 return b

Unlike the VALUES case this one is stable after the first pass, but it still changes prosrc:

• For PL/Python and PL/Perl heredocs, indentation is syntax. A uniform one-space shift happens to stay valid Python, but the formatter is editing code it does not parse.
• A multi-line string literal inside a PL/pgSQL body is shifted with the lines around it, so a function that builds SQL text builds different text (documentation example cs_update_referrer_type_proc).

This one is deliberate style inherited from pgfmt (tests/fixtures/river/create_function.expected expects the one-space indent), so the fix is a style decision: leave multi-line bodies verbatim, or reindent only languages libpgfmt understands and never inside a literal. Three documentation statements are listed for it in tests/fixtures/corpus/known_token_loss.txt (#59).