Add c++ binding/implementation thread safety options v2

[Kimeek42]

This solution adds 2 new virtual methods IBase::_lockInstance and IBase::_UnlockInstance on the implementation side with empty implementation. It also adds new class IBaseWithMutex that derives from Ibase. Those methods are being injected to base class methods so they will be exposed through and API (as private). It all happens only if one (or more) class has ThreadSafetyOption attribute set to "strict" or "soft".
Difference between soft and strict:
soft - binding side will call _lockInstance only if string / array is returned from API function
strict - binding side will call _lockInstance everytime, no matter what is returned from function

IBaseWithMutex Definition:
/**
 Definition of a class with mutex for IBase
*/
class IBaseWithMutex : public virtual IBase
{
private:
    std::mutex m_mutex;
public:

    /**
    * IBaseWithMutex::_lockInstance - If thread safety for class in library is enabled it should lock object for calling thread
    */
    virtual void _lockInstance() { m_mutex.lock(); }

    /**
    * IBaseWithMutex::_unlockInstance - If thread safety for class in library is enabled it should unlock object for other threads
    */
    virtual void _unlockInstance() { m_mutex.unlock();}
};

When ThreadSafetyOption attribute in LibraryManager component class is set to "soft" or "strict", ILibraryManager will derive from IBaseWithMutex instead of Ibase

class ILibraryManager : public virtual IBaseWithMutex {
public:
    ...
};
Example binding side functions created when ThreadSafetyOption is set to soft:
std::string CLibraryManager::GetLocalLibrariesPath()
{
    EagleAPI_uint32 bytesNeededPath = 0;
    EagleAPI_uint32 bytesWrittenPath = 0;
    _lockInstance();
    CheckError(m_pWrapper->m_WrapperTable.m_LibraryManager_GetLocalLibrariesPath(m_pHandle, 0, &bytesNeededPath, nullptr), true);
    std::vector<char> bufferPath(bytesNeededPath);
    CheckError(m_pWrapper->m_WrapperTable.m_LibraryManager_GetLocalLibrariesPath(m_pHandle, bytesNeededPath, &bytesWrittenPath, &bufferPath[0]), true);
    _unlockInstance();
    
    return std::string(&bufferPath[0]);
}

void CLibraryManager::RefreshLocalLibraries()
{
    CheckError(m_pWrapper->m_WrapperTable.m_LibraryManager_RefreshLocalLibraries(m_pHandle), false);
}

With this approach we are locking / unlocking mutex on implementation side so we can have 3 different instances of the Binding-Class pointing to the same Implementations-Class and all of this should work fine. On the binding side _lockInstance and _unlockInstance are private so one should use them by accident.
One more thing, CheckError will unlock hande in case of "exception propagation"

inline void CWrapper::CheckError(CBase * pBaseClass, EagleAPIResult nResult, bool unlockIfError)
    {
        if (nResult != 0) {
            std::string sErrorMessage;
            if (pBaseClass != nullptr) {
                GetLastError(pBaseClass, sErrorMessage);
                if (unlockIfError) {
                    _unlockInstance(pBaseClass);
                }
            }
            throw EEagleAPIException(nResult, sErrorMessage);
        }
    }

Just like with binding side, any changes on binding side will happen only when one (or more) class has ThreadSafetyOption attribute set to "strict" or "soft".