The quiet ignoring of deprecated GMT 4 options

Major options in GMT have changed over time . This annoys long-time users so we only make such changes when we must, and we have let the "old ways" be allowed for quite some time now (GMT 5 was released in 2013). There seems to be several types of compatibilities:

1. Some modules used one option letter (say **-A**) for a feature and now uses another letter (say **-B**) for the same feature. Examples might be **-W** for histogram width in pshistogram which now is **-T**_inc_ since this allows us to have a much more flexible setup for bins. If the user specifies the old **-W** we do figure out what to do, but we do not give a deprecated message.
2. In other modules, such as psrose, the old **-C** was replaced by **-E,** and if we find **-C** we print `"Option -C for mode-vector(s) is deprecated; use -E instead."`. However, it is only printed if the compatibility level is 5.
3. For some common options from the past we quietly accept them. Here is the code:

```
case 'Z':
if (!gmt_M_compat_check (GMT, 4)) error++;
break;
case 'E':
if (gmt_M_compat_check (GMT, 4))
error += GMT->common.p.active == false;
else
error++;
break;
case 'm': if (!gmt_M_compat_check (GMT, 4)) error++; break;
case 'S': if (!gmt_M_compat_check (GMT, 4)) error++; break;
case 'F': if (!gmt_M_compat_check (GMT, 4)) error++; break;
```
So those with long memory will remember that **-F** used to set pixel grid registration (currently **-r**), **-S** used to set 2-d spline boundary conditions (currently **-n**), **-Z** set 3-D z-level (now in **-p**), **-E** set perspective view (**-p**), **-m** told GMT 4 to expect a multi-segment file (now automatic). With the **GMT_COMPATIBILITY** = 4 stuck as is forever, no message at all may be given (e.g., #3455). I have to do this to get an error:

```
gmt blockmedian -R-2/2/-2/2 -I1 -S t.txt --GMT_COMPATIBILITY=5
blockmedian [ERROR]: Unrecognized option -S
```

Note that the check here is crazy since **blockmedian** never had a **-S** but it gets caught up in the common option parsing. I also seem to remember that we pushed the **GMT_MSG_COMPAT** verbose warning down the list so as not to annoy people. Yes, adding **-Vc** to the **blockmedian** call gives no error, so that part is broken I guess.

We need to make some changes. Here is a list of possibilities:

1. In GMT modern mode, we should absolutely, positively not honor old deprecated options. What a nightmare, but there is no code that takes this into account presently.
2. When do we increase the default setting on **GMT_COMPATIBILITY**? 2025? Surely, with 6.1 coming out 7 years after GMT 5, maybe inch it up to at least 5? If people are still running ancient GMT 4 script they expect to work then they do need to get with the program and make changes or just install GMT 4 for those tasks.
3. GMT 4-ever: Leave as is but go back and add annoying compatibility messages when these things happen, don't quietly let bad shit go down.

Feedback please, @GenericMappingTools/core.