Fix ASAN warning caused by global initialization order using CryptoPP functions

[wezrule]

Fixes ASAN warning Mac/Clang:

[1m/Users/user/Library/raiblocks/crypto/cryptopp/randpool.cpp:46:4:[1m[31m runtime error: [1m[0m[1mreference binding to null pointer of type ‘const CryptoPP::NameValuePairs’[1m[0m
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /Users/user/Library/raiblocks/crypto/cryptopp/randpool.cpp:46:4 in
[1m/Users/user/Library/raiblocks/crypto/cryptopp/cryptlib.cpp:61:64:[1m[31m runtime error: [1m[0m[1mreference binding to null pointer of type ‘const CryptoPP::NameValuePairs’[1m[0m
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /Users/user/Library/raiblocks/crypto/cryptopp/cryptlib.cpp:61:64

This is because our ledger_constants globals variable is initialized with globals from CryptoPP which haven't been properly initialized yet. There is not specified order of global initialization within different translation units. The problem specifically comes from:

random_pool.GenerateBlock (not_an_account.bytes.data (), not_an_account.bytes.size ()); in the ledger_constants constructor. This ultimately uses a default argument of const NameValuePairs &params = g_nullNameValuePairs but g_nullNameValuePairs has not been initialized yet.

I have modified it to use lazy initialization when the nano::not_an_account is used and made it thread safe as well.

not_a_block is not used so has been removed

[cryptocode]

ledger_constants

This changes completely with #1729

[SergiySW]

Probably in upgrade_v12_to_v13 it could be local variable copy?

[wezrule]

@cryptocode I think it still needs to go in as we want this in v18

@SergiySW Good idea, and done.

I've removed the circular_buffer changes to make the diff more concise

[cryptocode]

@wezrule yeah, comment made before milestoning. LGTM.

[SergiySW]

LGTM