[ulgens]

Fixing whitespace-related issues using

• https://prek.j178.dev/0.5.2/builtin/#end-of-file-fixer
• https://prek.j178.dev/0.5.2/builtin/#trailing-whitespace

Modern IDEs tend to apply these fixes whenever you edit the related lines / file, which causes noise and pollutes unrelated commits.

The diff is not small, but being one of the most basic git hooks - styling fixes, I believe this is important to have.

[ilyamandel]

I realise that all the changes should be very benign, but I am still a bit apprehensive to apply this to so many files at once, where we clearly don't have the capacity to manually check... I'll leave it to @jeffriley to make the call, since some of the affected files include core C++ code.

[jeffriley]

I'm all for a consistent style, but all the C++ files will be replaced by the new version soon - some files will disappear entirely, and new files will be added. I'm not sure applying these style changes to the C++ files now is worth the effort of reviewing the changes (I agree with @ilyamandel that the changes should be benign, but I'd bet that everybody that submits a PR believes the changes are good... so they should be reviewed - and even a cursory review of 268 files is a bit onerous). And as far as changes to the markdown documentation files go - yes, the changes should be benign, but someone needs to look at the result to confirm that.

Maybe do each type of file as separate PRs - that would reduce the onerous nature of a giant PR, and enable people to review files that suit their expertise (e.g. @ilyamandel for matlab files).

I'm out for 3 weeks or so in about a week, so I couldn't even start looking at this until the end of November or so.

EDIT: I forgot to add:

I'm not sure the problem fixed by this PR actually hurts us - having a tab or one or more spaces at the end of a line (especially if it's a comment) doesn't seem to me to be terribly problematic. Sure, if there are so many spaces at the end of a line that it affects how the file is displayed in an IDE, that's an issue - but we'd pick that up in a PR review wouldn't we? Same for too many blank lines at the end of a file. Maybe automating removing those things is useful, but only if it doesn't cause us more work - if we can prove that the automation always produces benign results (so that we don't have more reviewing work), then I'm ok with adopting it.