C-API: inconsistent behaviour for missing mods between C and Matlab

[CarawaySeed42]

Description:
If only a subset of modifiers are defined in ROAD_CRG_MODS section of crg header,
then the behaviour of the C- and Matlab-API differ.

Example mods section:

$ROAD_CRG_MODS
refpoint_x = 1
refpoint_y = 1
refpoint_z = 1
refpoint_phi = 3.141
GRID_NAN_MODE=2

Since neither refpoint_u, refpoint_u_fraction, nor refpoint_v and refpoint_v_fraction are defined the APIs decide the following:

Matlab API:

• Use refpoint_u_fraction = 0
• Use refpoint_v = 0

C-API:

• Use refpoint_u_fraction = 0
• Use refpoint_v_fraction = 0

Result:

• Matlab-API uses start of centerline at v=0 as reference point
• C-API uses start of centerline and right border as reference point

--> At the moment, one has to provide refpoint_v or refpoint_v_fraction in the mods section or the APIs will return different results.

Proposed change:
Since having the reference point at v=0 makes more intuitive sense, the C-API should mirror this behaviour in the following lines:

OpenCRG/c-api/baselib/src/crgLoader.c

Lines 2969 to 2973 in 2530b4e

	if ( !crgOptionIsSet( &crgData->modifiers, dCrgModRefPointVFrac ) && !crgOptionIsSet( &crgData->modifiers, dCrgModRefPointV ) )
	{
	crgOptionSetDouble( &crgData->modifiers, dCrgModRefPointVFrac, 0. );
	crgMsgPrint( dCrgMsgLevelNotice, "crgCheckMods: setting value of modifier \"refpoint_v_fraction\" to 0.0.\n");
	}

Note:
There is probably a lot more differences in API behaviour regarding mods, but this is the most remarkable one

[CarawaySeed42]

I realized, this should probably be for Milestone 3.0 because I know at least one case were correcting this behaviour breaks the users workflow.
-> Up to discussion, if that is a breaking change for a major revision