Revert most of #438 and improve const-correctness

[imwints]

Reverts the removal of const-qualifiers on bools.

Even if this produces the same binary it is good practice to be const-correct and not let developers accidentally change variables that shouldn't be modified

[stefanos82]

At least the function parameters keep them as is, they are passed by value, not by const reference or const pointer; therefore the compiler will optimize them out.

[imwints]

It is not about what the compiler produces. In fact, the generated binary is identical to the one without const. It is about self documenting code and guarantees.

Take this bit from btop_tools.cpp:

bool refresh(bool only_check) {
	struct winsize w;
	if (ioctl(STDOUT_FILENO, TIOCGWINSZ, &w) < 0) return false;
	if (width != w.ws_col or height != w.ws_row) {
		if (not only_check) {
			width = w.ws_col;
			height = w.ws_row;
		}
	return true;
	}
return false;
}

If you want to know what only_check is for just by reading the declaration you cannot be certain that only_check is just used to control the flow of the function. The value might change depending on the function body and might not be used as you wished when you called the function.

If you see bool refresh(const bool only_check); you can be certain that this is to switch the functions control flow, and only that. The compiler enforces that the value is not changed. It also makes it harder to deviate from the original authors intention for that variable.

If a variable is not intended to be modified it should be declared const to document the code and provide a bit of intention.

It's not ideal that C++ is requiring you to explicitly make variables const unlike rust where mutability is opt-in but we should at least make it harder for everybody to make mistakes and declare as much const as possible

[stefanos82]

It's not ideal that C++ is requiring you to explicitly make variables const unlike rust where mutability is opt-in but we should at least make it harder for everybody to make mistakes and declare as much const as possible

As I have suspected...well, I'm off; good luck.

[imwints]

What's the issue?

[aristocratos]

@nobounce
Good effort 👍🏼

But I'm gonna hold off a bit on merging this since it touches code in a lot of places and will cause a lot of messy merges to code still in work in PR's and some branches.
Will probably be less of a pain to merge main in to this PR after the other code has gone in than the other way around.

Have some big improvements planned from a related project I worked on recently.

[imwints]

Sounds reasonable, most of this work was done with clang-tidy anyways, so easy to redo (or rebase)