Windows' native terminal, `conhost.exe`, lacks font fallback support.
This causes some of the characters used in `wttr.in`'s terminal output
to not be displayed at all - placeholders are supplied in their place.
This PR provides a mode that, when enabled, translates missing glyphs
to ones available on every platform without (*I believe*) making any
compromises regarding their meaning; see translation table below.
| Character | C-UCP | Replacements | R-UCPs |
| :--------------- | :----: | :------------------------------------ | :----: |
| NORTH WEST ARROW | U+2196 | BOX DRAWINGS LIGHT ARC DOWN AND LEFT | U+256E |
| NORTH EAST ARROW | U+2197 | BOX DRAWINGS LIGHT ARC DOWN AND RIGHT | U+256D |
| SOUTH EAST ARROW | U+2198 | BOX DRAWINGS LIGHT ARC UP AND RIGHT | U+2570 |
| SOUTH WEST ARROW | U+2199 | BOX DRAWINGS LIGHT ARC UP AND LEFT | U+256F |
| HIGH VOLTAGE SIGN | U+26A1 | BOX DRAWINGS LIGHT DOWN AND RIGHT + UP AND LEFT | U+250C + U+2518 |
It seems reasonable, per the documentation (under the section, "Weather Units"), that `?M` would enable metric ("metric (SI), but show wind speed in m/s") all by itself.
> By default the USCS units are used for the queries from the USA and the metric system for the rest of the world. You can override this behavior...
> ...
> `curl wttr.in/Amsterdam?M` # metric (SI), but show wind speed in m/s
In the USA, we have to pass `?m&M` (`https://wttr.in/?m&M`) to get metric and meters/second. If we just pass `?M`, we get USCS units for everything else and windspeed in meters/second.
The postprocessing method assumes that the sout data is always delivered in the same format. If the location is not found, the passed format deviates and this then leads to an incorrect behavior => incorrect return value.
Close#729Close#728