new cape_open_error constructor fails on null pointer

[jasper]

The newly added constructor

cape_open_error(CapeResult _errorCode,ICapeInterface *object=nullptr)

fails with a null pointer exception in case object is null.

This constructor was added in COBIA 1.2.0.10, see item #127

[jasper]

The failure only occurs for COBIAErr_CAPEOPEN error codes.

[jasper]

Correction - this is not new constructor added in #127

[jasper]

I suggest this implementation to guard against a null pointer error:

	cape_open_error(CapeResult _errorCode,ICapeInterface *object=nullptr):
#ifdef _WIN32
		utf8description(nullptr),
#endif
		cause(nullptr),
		errorCode(_errorCode) {
		COBIA_ASSERT(errorCode!=COBIAERR_NoError,"exception for COBIAERR_NoError");
		if (errorCode==COBIAERR_CAPEOPENError) {
			if (object) {
				//get the exception that caused this error
				object->vTbl->getLastError(object->me,cause);
			} else {
				COBIA_ASSERT(false,"COBIAERR_CAPEOPENError must have an associated object");
			}
		}
	}

[jasper]

In [161d208924fa145b815fd5201d02916a57780119]:

Fix #148

[michelpons]

Is the newly implemented logic: cape_open_error returns an error code and an object that is a ICapeInterface. If the error code is a CAPE-OPEN error code, and if the object is not a Null pointer, object can be accessed for more info otherwise the implementation is somewhat in error since the associated object should be there for a CAPE-OPEN error.
Are we protecting against an implementation error of some sort, implementation error in a COBIA-based application?

[jasper]

The previous implementation crashed when raising an cape_open_error of type COBIAErr_CAPE_OPEN, with a null pointer for the object that raised it. Although this is not valid, there should not be a crash when doing this. The current implementation fixes that, and asserts so that the developer can check what is causing the issue.

This was detected by marshalers raising an invalid error, which crashed the test that was run.