[VTR][LOG] Improved Unused Arg Warning Suppression

[AlexandreSinger]

Previously, VTR's logging used sizeof static casted to void in order
to suppress the unused argument warning when we want logs to be a NOP.

The sizeof operator may have some strange affects, but since the code
is NOP anyways thats not a huge deal. The reason for this change is that
intellisence that use clangd flag this as a potential issue causing
warnings.

This also exposes a potential issue where a LOG message is using a
function that may have memory effects, so it may not be cleaned up by
the compiler properly. The unused variables should be handled
explicitly.

Also moved static variables from the header file of vtr_log to the
implementation. No functional change, but just prevents these variables
from being present and accessible in every file that uses vtr_log (which
is alot).

[AlexandreSinger]

Well. Now I have seen everything. Removing the sizeof operator actually did have a substantial performance impact on some test cases. I killed CI just to be safe and will investigate further. If sizeof is the only way so be it, but this is bizzar to me...

[AlexandreSinger]

I realized what is going on here. The way these arguments are being ignored may actually expose a problem. Imagine the following case:

VTR_LOG("Value that I am interested in: %f\n", func_with_mem_effects(dyn_val));

This previously got turned into:

static_cast<void>(sizeof("Value that I am interested in: %f\n"));
static_cast<void>(sizeof(make_tuple(func_with_mem_effects(dyn_val)));

But lets assume that func_with_mem_effects has memory effects (sometimes not as easy to tell), then the compiler would not necessarily optimize this function away; especially if this is a complex function that is never inlined. It could be possible that some of these log statements may be still taking runtime even when debugging is off!

I have noticed that VTR_ASSERT has the exact same problem. This should be investigated. There may be performance being wasted without reason beyond just usability. Maybe sizeof bypasses this, but I have my doubts on this...

[AlexandreSinger]

I was reviewing the use of sizeof in the standard library and found why we are using it in this way:

https://en.cppreference.com/w/cpp/language/sizeof

Although this is improper it seems to actually avoid performance concerns since the expressions within sizeof are never evaluated! This may make this PR useless, besides making intellisence errors go away.