Keep quoted sections intact when pretty printing shell form arguments

[Eljees]

Fixes #90.
Fixes #57 — the same Text.words call causes both, so one change closes them together.

What happens

prettyPrintArguments splits the argument text with Text.words, so a quoted section is cut into words like any other text. Two things follow: an && written inside quotes matches the helper that inserts a line break, and the spacing inside the quotes is rewritten when the words are joined back with a single space each.

On master, parseText followed by prettyPrint turns this

RUN grep -F 'cd dir && ./run.sh ' /opt/Makefile
RUN echo 'a    b'

into this

RUN grep -F 'cd dir \
 && ./run.sh ' /opt/Makefile
RUN echo 'a b'

The first one is no longer the same command: grep gets cd dir and the remainder becomes a separate stage of the shell line.

The change

Split on whitespace only outside quotes, so a quoted section stays part of the word it belongs to. An escaped character is kept with its word as well, since an escaped space does not end one. Words are still joined with a single space, so nothing changes for unquoted text.

Same two lines after the change, plus a control that a real && still breaks:

RUN grep -F 'cd dir && ./run.sh ' /opt/Makefile
RUN echo 'a    b'
RUN apt-get update \
 && apt-get install -y curl

Tests

Three cases added to the pretty print RUN group: the two above, plus the control. The first two fail on master — RUN grep -F 'cd dir \\n && ./run.sh ' ... and RUN echo 'a b' — and pass with the change; the control passes both before and after.

cabal test goes from 309 examples / 2 failures to 309 examples / 0 failures on GHC 9.8.4.

[Eljees]

@m-ildefons a short nudge — this has been green and conflict-free for a week.

It closes #90 and #57 together, since the same Text.words call causes both. If you would rather look at them apart, say so and I will split the spacing half into its own PR.

One thing worth flagging given #116 is open: this touches prettyPrintArguments, so if the multiline shell work lands in the same function I am happy to rebase on top of it rather than the other way round.

[m-ildefons]

Sorry I missed this.
This looks pretty good. I'm away for the weekend now, but I'll try to take a closer look early next week.

Wrt. #116, don't worry I'll manage rebasing #116 if necessary