Revisit the handling of hyphen-minus inconsistence

[seisman]

Related to #196, #198, #391, #644.

Sorry to be too picky. I'm not quite satisfied with how GMT handles hyphen and minus.

See the script and the generated figure below as a possible use case. If I don't have much knowledge about the difference between hyphen and minus, I think I would be confused why spaces in a string change the appearance of -.

gmt begin isolatin png
gmt basemap -R-10/10/-10/10 -JX10c/10c -Baf
gmt text -F+f18p << EOF
0 0 123 - 456
0 2 123- 456
0 4 123 -456
0 6 123-456
0 -2 ABC - DEF
0 -4 ABC- DEF
0 -6 ABC -DEF
0 -8 ABC-DEF
EOF
gmt end show

I know that GMT internally converts some hyphens to minus, following some rules. I don't know the exact rules, but I think it's based on the definition of hyphen, as mentioned in comments of previous issues/PRs:

a short line (-) used to connect the parts of a compound word or the parts of a word divided for any purpose

However, I don't think the definition is always true. I can imagine many use cases where I need a hyphen, not a minus. For example, command line option -B should use a hyphen, instead of a minus. Sometimes, we even need a en-dash or a em-dash. I don't think there are perfect rules to determine when a hyphen should be used or not.

Actually, I quite like the idea proposed by @PaulWessel in #196 (comment).

1. When GMT is plotting annotations etc. we know we are dealing with numbers and hence we select the minus code. That code differs across char sets. This ensures uniformity and compliance to proper math type setting.
2. For free-standing text provided via pstext or -B etc, we are not concerned with formatting numerical data and any "-" character will be considered to be a hyphen and we insert the correct hyphen code, which also differs across char sets. This also ensures consistency and avoid using very wide dashes (en-dash is very similar to math minus) in hyphenated words.
3. If you are very picky and want to write -200 in some text string and want the minus symbol then you can use the octal code for perfection.

I think we should follow the idea, and let users decide which one to use. The only exception is annotations, as pointed by the first point of Paul's comment, in which we should always use a minus.

[PaulWessel]

To implement the idea from #196 we would need a new flag in the PSL structure to tell us if we are dealing with annotations or arbitrary text, since the switch from minus to hyphen etc in the PS code happens inside postscriptlight, and that function (psl_fix_utf8) is clueless as to what is being passed. Something like
PSL->current.numeric = true|false;
If true then we ensure we are using minus symbols, else we enforce hyphens. The parameter will need to be set to true by the -B functions that annotates axes, then reset to false before labels, etc.

[seisman]

Can we do the switch outside postscriptlight, e.g. in the -B functions?

[PaulWessel]

No, we don't want to. I think the spirit of the above is that we always want to use minus sign when we place annotations and use always hyphens elsewhere, but users can override the latter with octal codes when they see fit.