dockerfile: carriage return conflicting with heredocs

On Windows clients, the editor can add a carriage return character next to the newline. In certain situations this can cause the build to fail.

Eg.

 # cat Dockerfile| base64
ZnJvbSBhbHBpbmUNCnJ1biBlY2hvIG9sZFwNCiAgc3R5bGUgPiAvYmFyCnJ1biA8PGVvdA0KICBzZXQgLWUNCiAgZWNobyBoZWxsbyA+IGZvbw0KZW90DQo=

from alpine
run echo old\
  style > /bar
run <<eot
  set -e
  echo hello > foo
eot

Will fail with

 => ERROR [3/3] RUN <<eot (set -e...)                                                                                                                                                                                                           0.3s
------
 > [3/3] RUN <<eot (set -e...):
0.252 /bin/sh: set: line 0: illegal option -
------
Dockerfile:4
--------------------
   3 |       style > /bar
   4 | >>> run <<eot
   5 | >>>   set -e
   6 | >>>   echo hello > foo
   7 | >>> eot
   8 |
--------------------

failed to solve: process "/bin/sh -c set -e\r\n echo hello > foo\r\n" you can see the \r after set -e that is causing the issue.

To fix it for RUN statements seems trivial as we can just replace the values before passing. For COPY it gets more tricky as it isn't completely out of the question that the user wants to copy CR character. We could just not allow that. Maybe there are better solutions?

I'm not sure if there are any other possible cases outside of Heredocs. Above I provided an example of an old style \ line continuation, and it doesn't seem to be affected as it just concatenates everything into a single line.

This also could cause cache misses between Windows and Unix clients even if we patch the error cases. Ideally CR should not cause any behavior differences.

@jedevc @AkihiroSuda

Start by reproducing the Windows-style Dockerfile example and compare it with the Unix-newline version, focusing on heredoc RUN handling and the reported cache behavior. Trace how carriage returns are handled for RUN and COPY, then verify that heredocs no longer fail or differ across newline styles while COPY semantics remain appropriate.