Handle literal strings better

[gynt]

The original binary has strings that were used as literal strings stored in a particular section of the binary. To achieve 100% via reccmp-reccmp, we need to invoke STRUCT_RESOLVER like so:

MACRO_STRUCT_RESOLVER(char const[], false, (Address::SHC_3BB0A8C1_0x005A6CC4)) pWAV;

assert *pWAV::ptr == ".wav";

This is a shortcoming of reccmp-reccmp, it could easily check if the string from the source code is the same as the string in the original binary, and then consider the match 100%.

See example:

If this is addresssed, the address enum file can be reduced as it doesn't need addresses of literal strings anymore.

Further thoughts:

This doesn't work either, the reccmp isn't happy.

char const* const WAV = ".wav";

So currently, reccmp is only happy about the STRUCT_RESOLVER method.
It does get 100% if this is used:

// STRING: STRONGHOLDCRUSADER 0x005A6CC4
char const* const WAV = ".wav";

Which leaves us with the conundrum of naming the strings.

[TheRedDaemon]

Copy of my message to you regarding the string handling:

[...] regarding the strings, I only see two "clean" options.

We remove the strings from our completion status target and address file and simply make sure we are not stupid and provide the >wrong strings. In this case you can even try to export the literals to a global string constants file. As said, I prefer constants, even for >short strings.

Or the other way, over the resolver concept, which would include them in our addresses and status files.

No idea how reccomp behaves in the constant vs. the inline vs. the resolver (ref or instance) case. But I rather would then want to >know how this two concepts work together with it...

[gynt]

Current proposal:
Header file with constant strings and reccmp // STRING annotations. cpp files that use these global literals should include the strings hpp file.

The file could be named src/OpenSHC/OpenSHC-strings.hpp

POC:
openshc-strings.txt