Do not shadow LOCK's criticalblock variable for LOCK inside LOCK #8472

This is a followup to #8105, implements task 3 from it.

LOCK macro declares its variable criticalblock. When LOCK is used in nested block, again, the variable named criticalblock is used. When compiling with -Wshadow, this emits warning.

This change renames the variable criticalblock to criticalblockn, where n is ordinal number of the variable in the compiled file. Macro __COUNTER__ is used for this. It is supported by gcc (https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html), clang (http://clang.llvm.org/docs/LanguageExtensions.html) and Visual Studio (https://msdn.microsoft.com/en-us/library/b0084kay.aspx).

utACK 33d15a3a76d073986337adcd62646d93e7ba223f

More ACKs please.

utACK 33d15a3

I'd probably use LINE which is defined in the standards, but in practice it probably doesn't matter.

@luke-jr __LINE__ was thought of first, but @theuni raised "valid" (but not used yet) use-case (https://botbot.me/freenode/bitcoin-core-dev/2016-08-05/?msg=70857153&page=4):

std::mutex m1;
std::mutex m2;
LOCK(m1); LOCK(m2);

Of course you can use LOCK2 then instead, but...

Using __COUNTER__ allows even this use-case.

@paveljanik just to clarify, I was being snarky there. I don't think that's a real worry. In fact, 2 locks on the same line would almost certainly be wrong, as they should be std::lock()ed for safety anyway. So either way is fine with me.

utACK 33d15a3a76d073986337adcd62646d93e7ba223f

@theuni Ah, OK. Then I think we SHOULD use the standard __LINE__ even if __COUNTER__ works in all environments...

Using __LINE__ would result in a non-obvious error message, I guess. No strong opinion either way.

So let's go with __COUNTER__ and we will see if it is problematic on some systems or if it is de-facto-standard.

Microsoft, gcc and clang implement __COUNTER__ so I'd say that's good enough.

We could even fall back to shadowing if it's not defined?

Let's try it and see.

ACK, checked that bitcoind stays the same between 6e6ab2c and 33d15a3.