Issue title: Polygon holes filling is tricky
 Issue body: It seems that adding **-Ph** to headers is not enough. It needs that the hole polygon has an orientation contrary to its parent. But that's not all, if origin is not at LowerLeft (for rectangles) wholes are painted too regardless if its orientation.

```
cat << EOF > quads.dat
> -Gred CCW
0  0
5  0
5  10
0  10
0  0
> -Ph  CW
2  1
2  3
4  3
4  1
2  1
> -Ph  CCW
2  4
4  4
4  6
2  6
2  4
> -Ph CCW origin TopLeft
2  9
2  7
4  7
4  9
2  9
> CW -Gblue
5  0
5  10
10 10
10 0
5  0
> -Ph  CW
7  1
7  3
9  3
9  1
7  1
> -Ph  CCW
7  4
9  4
9  6
7  6
7  4
EOF
gmt plot quads.dat -JX12c -Ba2f1WSen -R-0.5/10.5/-0.5/10.5 -Gred -W1p -png map
```
![map](https://user-images.githubusercontent.com/537321/79698965-397cde00-8284-11ea-8875-b8645a86655c.png)

 Comments: 
 Comment 0: Yes, I think that is true.  Software that writes polygons with holes will ensure the orientation is consistent (e.g., inside is to the left as you walk around the perimeter).  I am pretty sure shapefiles do this correctly.   We do not reverse holes as we assume they are placed correctly.  if you ensure this orientation, does it then work?
 Comment 1: Curiously there was a thread in GDAL list about holes and Even said that GDAL does not care about the parent-child orietation. And PostGIS doesn't care either (and plots holes correctly).

But aside from the orientation there seems to be another issue that looks like a bug. Third square on reds should be transparent bit it's not because origin is not the same (TopLeft instead of BottomLeft).
 Comment 2: The 3rd square is CCW like the parent so no hole.
 Comment 3: If we must, we have code in gmtspatial to determine handedness and could reverse holes etc.
 Comment 4: True about 3rd. I got lost with so many looks at the Clock.
I thought on that ``gmtspatial`` option. Worth trying (at polygon plotting time) though I'm curious in what will happen from Julia.  The thing is, for those cases, from Julia I don't make a copy of data coming from GMT, just a direct memory access. Don't remember what happens when same data is sent back to GMT and it changes it because of bad handedness (kind of 1D transpose).
 Comment 5: It seems we can bury something deep in gmt_geo_polygons.  It plots the parent polygon (the usual case is to plot a single polygon), but then we loop over all the holds that might follow.  I think we can (a) detect that there are holes, (b) then determine the handedness of the parent, and (c) get handedness of each hold and reverse if matches the parent.  I will give that a try.
{'source': 'GithubIssues', 'repo_name_with_owner': 'GenericMappingTools/gmt', 'issue_id': 602811878, 'repo_stars': 692.0}