Add a gdal::GCP class to make GCP handling from C++ easier

[rouault]

GDAL_GCP is a C-only structure. The typical/recommended pattern to create GCPs from C is:

GDAL_GCP* gcps = (GDAL_GCP*)CPLMalloc( count * sizeof(GDAL_GCP) );
GDALInitGCPs( count, gcps );  // zero-initialize  pixel,line,x,y,z double members of each gcps[], and affects a CPLStrdup("") string to pszId and pszInfo members of each gcps[]
CPLFree(gcps[0].pszId); // free the initial empty string
gcps[0].pszId = CPLStrdup("foo"); // for example
GDALDeinitGCPs( count, gcps ); // free memory of gcps[i].pszId and gcps[i].pszInfo
CPLFree(gcps); // free the array itself

This is "fine" for a C user, but quite tedious in a C++ context. Big users of creating GCPs are GDAL drivers themselves.

So we introduce a gdal::GCP class that has a single GDAL_GCP private member, and handle memory allocation/deallocation, with helpers to navigate between the C and C++ worlds.

No attempt has been made (yet?) to modify the C++ API, in particularly the GDALDataset::GetGCPCount(), GetGCPs(), SetGCPs() method. I guess we'd need to keep the existing methods to avoid breaking external code, as wrappers over new methods that would return / accept std::vector<gdal::GCP>

(This is an alternative to the messy earlier attempt of #9191)

@dg0yt @dbaston thoughts?

[coveralls]

coverage: 68.831% (+0.006%) from 68.825%
when pulling 1e7aed6 on rouault:gcp_cppification
into 64cf9b4 on OSGeo:master.

[rouault]

@elpaso any opinion on this?

[elpaso]

@elpaso any opinion on this?

Good work!
Much nicer to use for C++ consumers.

[rouault]

This is ready for review