Fix line separator detection not considering form feed as white space

[robsdedude]

While working on #1966, I this bit of code that didn't seem quite right given that Python considers , \t, and \f all as white space (see https://docs.python.org/3/reference/lexical_analysis.html).

Finding an example for a failing test took me a fair bit of time as the auto-detected line separator isn't used a whole lot.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.19%. Comparing base (17746ba) to head (c9a5d80).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2436   +/-   ##
=======================================
  Coverage   99.19%   99.19%           
=======================================
  Files          40       40           
  Lines        3090     3090           
  Branches      680      680           
=======================================
  Hits         3065     3065           
  Misses         14       14           
  Partials       11       11           

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[DanielNoord]

Just one nit about the typing. Rest LGTM, thanks!

[DanielNoord]

@robsdedude due to merge train settings we don’t auto squash commits in this project (we should probably change that).

Do you mind squashing yourself and pushing a single commit to the branch? Please tag me when you have done so as GitHub doesn’t give me a notification of it so I won’t know when to merge.

[robsdedude]

@DanielNoord thanks for the review. Squashed and pushed.

This is the 2nd time you're telling me to squash. I actually considered amending the commit right away and force pushing. But I know the other side, too. It's hard to re-review a PR when you can't see the diff between now and your last review (like it happens when git history is rewritten). So I decided not to. What's you preference here? Should I just force-push the changes from review comments or do you prefer them (like it happened here) to be a separate commit with the downside of you having to ask me to squash and ping once the PR is read to be merged?

[DanielNoord]

What's you preference here?

It depends 😅 Generally (in open source) I prefer PRs to be of such a size that it doesn't matter if they were force pushed. For example, I'm currently travelling and having to read up on a 200 line PR is quite taxing. Even if a later commit is just 10 lines I'll likely need to read everything again as the context isn't top of mind. (Of course line count is not always the best indicator of scope).

For larger PRs where part of the later commits are also about changing the actual design of the solution, follow up commits generally make it easier to review.

In cases like this PR force pushing is fine. Although @staticdev and I should probably just change the merge queue settings so we can do this ourselves without bothering contributors.