#9042 Fix the formatter's line endings on Windows and in CRLF files

On Windows, bsc -format wrote its output through text-mode stdout, so every LF became CRLF: rescript format rewrote LF files to CRLF and format --check reported every LF file. Formatting a CRLF file was not stable either, on any platform: the scanner keeps the CRs inside comments, template literals and raw JS, so those lines came out as CR LF beside the printer's plain LF, and text-mode output or an editor turned them into CR CR LF, adding a blank line on each run.

Formatting now reads the source with LF line endings and gives the result CRLF ones when the source's first line break is CRLF. bsc -format and res_parser -print res write stdout in binary mode, also inside a captured compiler request, and the editor format command keeps a CRLF document's line endings. With that, Windows CI runs the syntax roundtrip tests and the OCaml and ReScript format checks, whose file lists now go through xargs to stay under the Windows command-line length limit.

The rewatch format unit tests expected formatted output to have CRLF line endings on Windows, which was the text-mode output bug. They now expect each file to keep its own line endings, and check that a formatted CRLF file passes format --check and is left unchanged by format, through the in-process formatter.

The syntax test script read each file list in a while loop from a file and started a background job per file. Under MSYS on Windows that occasionally corrupted the names the loop read, so a test file was skipped, or, in the roundtrip tests now running on Windows, reported as a failure. The script now reads each list into an array before it starts any job.