[FUNCTION_WRAPPER] Add ostream overload approach

[TheRedDaemon]

Closes #28.

As draft first, since I went with a rather strange approach, I guess.
My thoughts were essentially:

• I want to add overloads, maybe even for enums one day.
• I want separate files.
• I do not want them to compile in case of EXE.

I went with the not recommended, unusual cpp-include, building basically one cpp file that I added to core.
So I went with the most complicated first.

I can backpaddle if I overdid it:

• We can leave out the mirror of the directory structure, assuming we will not have type name collisions.
• We can leave out the "cpp" include approach and instead work with adding an additional cpp to core for every overload, ignoring the filter for dll/exe (might be overkill anyway).
• We can go back to one file and only think about splitting again in case the file grows beyond 1000 or 2000 lines.

What do you think?

Being honest I was actually going with one file, but then I thought about the enums. But the enums as they are used in the function parameters are not enums currently, but aliased ints, etc, so as of now, there is nothing to gain by overloading enums anyway.
Unless we switch the int aliased enums in the function parameters to the actual enum type and only use the int version in case of structs...

[gynt]

Hmmm, what about a inline approach to avoid cpp files. I could even pregenerate the implementation for enums

// Color.hpp
#pragma once
#include <iostream>

namespace MyProject {

    enum class Color { Red, Green, Blue };

    // Must be marked 'inline' if fully defined in the header!
    inline std::ostream& operator<<(std::ostream& os, Color color) {
        // ... implementation ...
        return os;
    }
}

---

I just looked at your approach in more in-depth. I think it is a bit too much: if I want to add a stream overload for a type, I have to touch OStreamOverloads.hpp, OStreamOverloads.cpp and add a subfile according to the type's namespace in subdir OStreamOverloads/OpenSHC.

I think it can be reduced to two file(changes) per object type:
src/core/OStreamOverloads/OpenSHC/Audio/mss/UnkSoundFlagsAndLoopCount.hpp containing:

namespace OpenSHC {
namespace Audio {
    namespace MSS {
        // Declared as inline to make it possible to put them in .hpp files
        inline std::ostream& operator<<(std::ostream& os, UnkSoundFlagsAndLoopCount const& value)
        {
            return os << "{loopCount=" << value.loopCount << ", flagsUnk=0x" << std::hex << std::setw(2)
                      << std::setfill('0') << static_cast<int>(value.flagsUnk) << std::dec << "}";
        }

    }
}
}

src/core/OStreamOverloads/OStreamOverloads.cpp containing:

#ifdef OPEN_SHC_DLL

#include "OStreamOverloadsSupport.hpp" // and add the .cpp to the build process, or make the helper functions also inline!
#include "./OpenSHC/Audio/mss/UnkSoundFlagsAndLoopCount.hpp"

#endif // OPEN_SHC_DLL

I don't think the goal of the ostream logger is to log all functions at once, but only a subset of all 3600 functions we are going to implement, so inline isn't going to add that much (size and overhead).

[TheRedDaemon]

So 3 files, basically (2 base and 1 for every overload)?
The general cpp, the headers and the header for the precomp?
Or do you want to place the inline headers in the precomp?

The issue is that the function resolver needs to be aware of the overloads.
So at least the declaration needs to be present in the translation unit of the current resolver.