Re-enable testing suite

[bitcoinx2]

Reactivate the existing testing suite. Closes #4

These tests have apparently not used since the beginning of Spectrecoin. Most test vectors still refer to the base58 prefixes of ShadowCash (SDC) which is (presumably) the main reason why tests are failing.

Most notable changes:

• Add testing executable to CmakeLists (only for Linux at this point)
• Fix compilation issues that are due to changed function calls or removed functionality
• Update test vectors to reflect changes to the base58 prefixes

For changing the test vectors I assume that the tests themselves are still correct, i.e. I simply inserted the values expected by the test. Admittedly this is a bad practice but serves as a starting point to see which test units are still compatible with our current code base in general. Future work should focus on reviewing the used test values and verifying their plausibility with regards to the desired behavior of the wallet.

As it stands now, the tests can still be used for regression testing, i.e. verifying that future code changes do not change the current behavior of the wallet (which might not necessarily be the desired behavior).

There are still some open issues which appear on my system (linux 64 bit):

pathTemp /tmp/test_alias_1638013645_11356
Running 85 test cases...
1
unknown location(0): fatal error: in "extkey_tests/extkey_serialise": std::ios_base::failure[abi:cxx11]: CDataStream::read() : end of data: iostream error
.../alias-wallet/src/test/extkey_tests.cpp(337): last checkpoint
unknown location(0): fatal error: in "key_tests/key_test1": memory access violation at address: 0x00000010: no mapping at fault address
.../alias-wallet/src/test/key_tests.cpp(155): last checkpoint

*** 2 failures are detected in the test module "Alias Test Suite"

According to my investigation so far, extkey_tests/extkey_serialise fails in case of de-serialization of an empty vector of <unsigned char>. This might in fact be a bug in the code base, not in the test. I don't know what the desired serialization should look like.

I didn't investigate the memory access violation yet.

The current changes have only been tested on Linux so the build will probably fail for other platforms.