Let grd2xyz option -T write STL output file

[PaulWessel]

STL is the format used by 3-D printers. This PR simply implements a new -T[b] option in grd2xyz that represents the grid in the form of a triangularized 3-D body by enclosing the surface triangulation with the four sides and base to make an enclosed volume. We can either write an ASCII or binary representation, as explained in the STL documentation. With the help of a UH colleague who has a 3D printer I have implemented, debugged, and tested this option and I think it is stable enough to be included in 6.3. Below is an example of a quick-and-dirty 3D print from my colleague using the GMT-produced STL which apparently worked much better than Matlab (the full-resolution version will take 48 hours to print, apparently). I have added this figure to the grd2xyz documentation:

Because this is just an isolated option in one module, all tests pass and there are no potential issues. At the moment, there is no virtual file used to write this printer-specific data so that calling it from the externals will require sending output to a file. I doubt anyone in the externals would need to capture this in memory, e.g.

STL = gmt.grd2xyz (some grid, STL=binary);

but if so we can implement that later.

[anbj]

Very interesting. Have not studied the man-page or anything yet, but should this work?:

$ gmt grd2xyz -RNO  @earth_relief_30m -T
solid STL of @earth_relief_30m_p.grd generated by GMT 6.3.0_3e68b8d_2021.11.06 
facet normal 9.963971e-01 -8.471393e-02 4.033996e-03
        outer loop
                vertex 0.000000e+00 2.300000e+01 4.184500e+03
                vertex 5.000000e-01 2.350000e+01 4.071500e+03
                vertex 0.000000e+00 2.350000e+01 4.195000e+03
        endloop
endfacet
facet normal -2.027180e-01 9.792311e-01 3.435899e-03
        outer loop
                vertex 0.000000e+00 2.300000e+01 4.184500e+03
                vertex 5.000000e-01 2.300000e+01 4.214000e+03
                vertex 5.000000e-01 2.350000e+01 4.071500e+03
        endloop
endfacet
facet normal 9.462731e-01 3.233667e-01 1.134620e-03
[....]
endfacet
endsolid @earth_relief_30m_p.grd
double free or corruption (!prev)
Aborted

Maybe due to need of having input in projected units, so tried:

$ gmt grdcut -RNO -Gno.nc @earth_relief_30m
grdcut [WARNING]: (w - x_min) must equal (NX + eps) * x_inc), where NX is an integer and |eps| <= 0.0001.
grdcut [WARNING]: w reset from -9.079889 to -9.5
grdcut [WARNING]: (e - x_min) must equal (NX + eps) * x_inc), where NX is an integer and |eps| <= 0.0001.
grdcut [WARNING]: e reset from 33.497093 to 34
grdcut [WARNING]: (s - y_min) must equal (NY + eps) * y_inc), where NY is an integer and |eps| <= 0.0001.
grdcut [WARNING]: s reset from 57.966579 to 57.5
grdcut [WARNING]: (n - y_min) must equal (NY + eps) * y_inc), where NY is an integer and |eps| <= 0.0001.
grdcut [WARNING]: n reset from 80.834053 to 81.5

$ gmt grdproject -Ju+31/1:1 -F -C no.nc -Gno-utm.nc

$ gmt grd2xyz no-utm.nc -T
malloc(): invalid size (unsorted)
Aborted

[PaulWessel]

Oops, had a dumb bug where I wrote n_columns when I meant n_rows, so it crashed the first time someone tried a case where n_rows < n_cols...
Now fixed and your two cases run.