Robust handling of filename modifiers

GMT is not consistent in handling filename modifiers. For instance, it is assumed that any **+u**k modifier for grids to scale the x and y coordinates from km to m is always given in isolation from other modifiers. This is neither reasonable nor documented. Here I summarize what filename scenarios we need to handle.

- **Grids**: _filename_[=_id_][**+o**_offset_][**+n**_invalid_][**+s**_scale_][**+u**|**U**_unit_]. However, for netCDF files we may also use _filename_?_variable_[_index_] or _filename_?_variable_(_level_). Mixing of these two do not seem robust. And as mentioned, **+u**|**U** does not expect other modifiers to be present. This is a **bug**.
- **CPT**: _filename_[**+h**_hinge_][**+i**_dz_][**+u**|**U**_unit_]. The **+i** modifier is only used in grdimage and grdview I think and it is only dealt with there and stripped from the filename. However, that parsing clearly assume there are no other modifiers, so any **+i**_10_**+h**_50_ would see the **+h**_50_ silently lost. This is a **bug**.
- **Other**: Nothing yet, but who knows what the future holds.

Given that the symbols ? and = may be used in grid file names, it is useful to remember that a URL query has the form <_httpaddress_>?_param1=value1_&_param2=value2_... and that a gridfile may be remote, either via an URL or via the "@" mechanism.

Interpreting all these flavors is important when a remote file is given and we are to download it. Clearly, the modifiers need to be stripped to ensure valid file names, but once downloaded we do want to reattach the modifier so that the modules do as we want. An exception is the URL query where we _do_ want to pass all that stuff on as part of the remote "file name".

To simplify checking, we need a new macro _gmt_M_file_is_query_ (file) that robustly returns true when we have a true query. We have _gmt_M_file_is_url_(file) already but a query is that plus a question mark and at least one param=value sequence. This sets it apart from a remote netcdf file with layer specification.

As part of #3370 I will make the parsing and handling of the above modifiers more robust.