reimplement: SHC_3BB0A8C1_0x00471830 and support functions 100%

[TheRedDaemon]

The weird patterns in the copy functions made me use assembly in the end.
Maybe that is the origin, maybe it is not. I found no other way to recreate this pattern.
Is heavily commented.

Also, draft: There needs to be a type change in LowLevelMemory.hpp.

Closes #91 .

[TheRedDaemon]

Added logic comments, however, still needs change in class definition of LowLevelMemory.hpp, either confirmed to have happend in Ghidra, or via commit to main.

[gynt]

Can you change the name of file copyData+.hpp to something without the +?
Or split them up again in separate files or does that ruin the match?
I would like to stick to the philosophy of the flie location being locatable just by function name and namespace.

[TheRedDaemon]

I can simplify it again to copyData.hpp, but they need to be in one file (under the assumption that Global Optimization was not used by them). Here my comment:

    // NOTE: The calls to the copyData... functions are optimized in "copyData", which means the compiler knew the
    //   content of these functions. The most likely thing is that these functions shared a file. It does therefore only
    //   work if the resolvers are active.

This may happen to us in other cases, too. At least in any moment Ghidra has issues to reuse the ECX, we have to assume they shared a file, and we have to put them together for the perfect match.

[gynt]

I synced the change in .hpp in a1971f3

[TheRedDaemon]

Still requires a decision regarding file naming: Should I just call it "copyData"?

[gynt]

So the current decision comes down to the following:

Option A
Have different files for each function, which makes it (for DLLs) not possible for the linker/compiler to improve copyData to not inject multiple mov ecx, ... statements for each sub call. Therefore, copyData should be inline assembly as well.

This keeps the binding from function namespace to filename intact.

Option B
Put the functions in the same file, allowing the compiler/linker to optimize copyData. This is more true to the original.

This ruins the binding from function namespace to filename. We could also "encode" (or make it machine predictable), by renaming the sub functions to: copyData_0x001 etc. Then the _ denotes the sub-ness of the function. We could also say these were private functions of the class, which would call for _copyData_0x001.
Then we keep some predictability: function copyData_blabla is to be found in copyData.cpp

What do you think of my B naming proposal?