Code formatting

[dNechita]

PR Description

This PR continues the effort to introduce code formatting rules, initially discussed in #397 and further developed in #413 by @rgetz. Additionally, this PR provides a script that enables users to format the entire codebase.

PR Type

• [ ] Bug fix (a change that fixes an issue)
• [x] New feature (a change that adds new functionality)
• [ ] Breaking change (a change that affects other repos or cause CIs to fail)

PR Checklist

• [x] I have conducted a self-review of my own code changes
• [x] I have commented new code, particularly complex or unclear areas
• [x] I have checked that I did not introduce new warnings or errors (CI output)
• [ ] I have checked that components that use libiio did not get broken
• [ ] I have updated the documentation accordingly (GitHub Pages, READMEs, etc)

[dNechita]

V1:

• Extended the maximum line length from 80 to 100
• Prevented clang-format from reordering the includes on some files which was causing windows builds to fail (dns_sd.h, dns_sd_windows.c)
• Fixed 2 spelling errors in cmake-format.py

[rgetz]

Eventually (after this is merged), you will want to add something like this also here

 # Example .git-blame-ignore-revs file
    a926bba49c89a5b882cd298be3af2570b1e6252c # Formatting changes
    237de8a6367a88649a3f161112492d0d70d83707 # Automated refactor

[rgetz]

After fixing things - a pre-commit hook/check is needed to ensure that all future patches keep the style - or it will just start diverting...

[dNechita]

After fixing things - a pre-commit hook/check is needed to ensure that all future patches keep the style - or it will just start diverting...

I have an active PR (#1338) that implements a CI job that checks if code is formatted. The job will fail if it's not. Specifically, the job checks all changed files, applies formatting, and fails if even one is not properly formatted. The job is triggered on pull requests.