Use SHA1 and MD5 from Crypto++ instead of our own implementations

[danim7]

Opening as a draft to be ready after 3.0.1 release

Closes #181

What

Migrate MD5 and SHA1 hash algorithms from our own implementation to Crypto++'s.
We were already linking that library for MD4 and RSA, but the other crypto algorithms were directly implemented on aMule's source code.

The main goals of this migration are:

• security best-practice: do not re-implement crypto functions, use a library
• performance: using Crypto++ we get better performance: SHA CPU instructions where available, but also faster processing times on CPUs not having those instructions (check below)
• maintainability: reduced code size when delegating crypto functions to an external library

The RC4 algorithm migration to Crypto++'s version is out of scope. According to @Stoatwblr analysis here #194 (comment) , RC4 implementation in aMule is slightly broken vs Crypto++, and migrating to Crypto++'s version would actually inccur in a performance penalty because of the workarounds needed to make it work. We keep the existing implementation.
Also, credit to eMuleAI: SHA1 and MD5 migrations to Crypto++ are largely based on their code (SHA.* MD5Sum.*) here: https://github.com/eMuleAI/eMuleAI/tree/master/srchybrid

Tests

• Add new files to the shared folder. Compare known2_64.met files generated by the before-Crypto++ and after-Crypto++ versions. They shall be equal. Since entries in known2_64.met file do not follow any specific order, we need to delete the ~/.aMule folder for each version and add the shared files following the same order to generate identical known2_64.met files
• Set-up configuration as "Accept only obfuscated connections", successfully connect to a Server, check in the log the connection is obfuscated
• Set-up configuration as "Accept only obfuscated connections", successfully connect to Kad
• Set-up configuration as "Accept only obfuscated connections", successfully download a file from other clients, check on Client Details the connection is obfuscated
• Download a file, it shall hash correctly when the download is completed
• Login to a remote amuled from amulecmd/amulegui by typing a password

Performance

Performance comparison for SHA1 hash operations follows.
Since MD5 is only used to hash a few bytes (EC password, key agreement for RC4 encryption), the performance impact is assumed to be negligible.

Methodology

Before each test, remove ~/.aMule folder
Launch amule(d) to create the ~/.aMule folder, and close it.
Create three files in ~/.aMule/Incoming as follows and restart amule(d)
fallocate -l 300mb test-300mb
fallocate -l 2gb test-2gb
fallocate -l 5gb test-5gb
Measure start time from log line: SharedFileList.cpp(410): Found 0 known shared files, 3 unknown
Measure end time from known2_64.met modification time after all 3 files are hashed, since Release builds don't show any log line on hash completion.

Results:

amule on a CPU with SHA instructions:

type	time
aMule using Crypto++	14s
aMule using its own implementation, release build	44s
aMule using its own implementation, debug build	52s

amuled on a CPU without SHA instructions (RPi 400):

type	time
aMule using Crypto++	1min 1s
aMule using its own implementation, release build	1min 49s
aMule using its own implementation, debug build	3min 37s

[got3nks]

Great job @danim7, thanks.

Will mark it for 3.1.0.