[clang-tidy] Disable lints that frequently cause false positives

[fknorr]

Resolves #127.

There's two lints we would like to have but can't enable fully due to FPs:

• misc-const-correctness will suggest const accessor and const std::lock_guard, which is just noise. I've enabled this in the runtime, but disabled it for examples and tests - we don't constuct too many accessors in runtime code itself.
• misc-include-cleaner doesn't understand "interface headers" like <sycl/sycl.hpp> and will insist we include <hipSYCL/sycl/handler.hpp> et al. It also removes includes that are necessary for trait implementations, such as those of fmt::formatter.

I've manually performed autofixes for both these lints and added sensible corrections resulting from them as individual commits in this PR to clean up the codebase somewhat.

I also used the include-cleaner mayhem as an opportunity to set a consistent #include schema:

#pragma once // ONLY in my_interface.h
#include "my_interface.h" // ONLY in my_interface.cc

// 1 blank line, then all other headers form my module
#include "sibling_header_1.h"
#include "sibling_header_2.h"

// 1 blank line, then everything from the stdlib
#include <stdlib_header>
#include <stdlib_header_2>

// 1 blank line, then all 3rdparty deps
#include <3rdparty1/header.h>
#include <3rdparty2/header.h>

// 1 blank line, then any conditional includes (and maybe defines)
#ifdef ANY_CONDITIONAL_INCLUDES
#include <whatever.h>
#endif


// 2 blank lines, then the first actual token in the file
namespace celerity::detail {
...

I'm including my own headers before the stdlib or 3rdparty dependencies, because this is more likely to lead to a compiler error when another header forgets to include something. clang-format is smart enough to alphabetically sort includes within those groups.

I didn't bother with updating includes in tests in this PR.

[github-actions]

Check-perf-impact results: (32e33781a20e2a3976ece8f7dc81ae2b)

❓ No new benchmark data submitted. ❓
Please re-run the microbenchmarks and include the results if your commit could potentially affect performance.

[psalz]

I expected the diff to be a lot worse! Thanks!

I also used the include-cleaner mayhem as an opportunity to set a consistent #include schema:

Should we add that guide to CONTRIBUTING.md? 🤔

[github-actions]

⚠️ Clang-Tidy found issue(s) with the introduced code (1/1)

[PeterTh]

Nicely done, I really appreciate 2 main points of this:

• I love standardizing the header ordering, and I also like the reasoning for the 3 groups.
• We really do need to reduce the clang-tidy spam, and I agree with the vast majority of removals. I added notes on a small number of them.

What I'm ambivalent about is the sheer amount of includes that are the result of strict include what you use. But we decided on that earlier. I guess in some cases it might indicate which headers have too much responsibility or not enough encapsulation.

What I really don't like is (bikeshedding warning!) the extra newline. It also seems like this is the opposite of formalizing the established practice of our codebase, since it seems like there are far more files where it is added than there are others.

[github-actions]

⚠️ Clang-Tidy found issue(s) with the introduced code (1/1)

[coveralls]

Pull Request Test Coverage Report for Build 11975782234

Details

• 4 of 4 (100.0%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.009%) to 94.92%

---

Totals
Change from base Build 11971374757:	0.009%
Covered Lines:	7049
Relevant Lines:	7161

---

💛 - Coveralls

[fknorr]

Re newline: I don't feel strongly about this, but visually it does help me in files with huge include lists like instruction_graph_generator.cc.

And I agree the number of includes is a bit excessive, but I have trouble coming up with a much better rule dictating which includes must be present. We could though, for example, omit all includes from a .cc file that have already happened in the .h file of the same name.