Wolfram|Alpha is HTTPS-only: make the fetch command configurable, fix two changed error formats

[SpitfireTN]

Hello — thanks for Guru, it has been running on Reign of Fire BBS for a while.

It stopped working, and the cause turns out to affect every install rather than
just mine, so I thought it was worth offering back.

The problem

api.wolframalpha.com now answers port 80 with a 308 redirect to https://:

$ curl -s -o /dev/null -w '%{http_code} -> %{redirect_url}\n' \
    "http://api.wolframalpha.com/v1/result?appid=...&i=how+far+is+the+moon"
308 -> https://api.wolframalpha.com/v1/result?appid=...&i=how+far+is+the+moon

C:http_get (Aminet, 2015) speaks plain HTTP only and does not follow
redirects — there is no ssl/tls/location string in the binary — so Guru
can no longer reach the API at all. Every /v1/* and /v2/* endpoint behaves
the same way, so there is no plain-HTTP path left to fall back to.

What this changes

The fetch command and API root are now configurable instead of hardcoded:

g.fetchCmd = "httpget"                        /* AmiSSL 5, TLS on the Amiga */
g.apiBase  = "https://api.wolframalpha.com"

AmiSSL 5 ships a ready-built 68k httpget in Developer/Examples/AmigaOS3/
that uses OSSL_HTTP_get() — no libcurl needed, and it takes a URL much like
http_get did. That keeps everything on the Amiga.

For anyone who would rather keep http_get, pointing g.apiBase at a
plain-HTTP proxy that performs the TLS leg also works.

http_get takes -u, AmiSSL's httpget takes the URL alone, so
fetchWebRequest builds whichever form applies. The startup existence check
and its error message follow g.fetchCmd too — otherwise a correct AmiSSL
install gets rejected at launch.

Two response formats also changed

Both stopped Guru's own error handling from matching:

• An invalid AppId now returns a bare Invalid appid, not
  Error 1: Invalid appid. A bad key fell through and was displayed as if it
  were an answer instead of reaching badAppId.
• 501 bodies now arrive quote-wrapped:
  "Wolfram|Alpha did not understand your input". The == tests missed, so
  the error printed as a genuine answer with the "powered by Wolfram|Alpha"
  footer attached.

The unwrapping is deliberately narrow — it only applies when the unwrapped
text matches one of the known error strings, so a real answer that happens to
be a quotation is left alone. It also sits ahead of your
noShortAnswer -> sorryDave step, so a quoted "No short answer available"
now reaches it correctly.

Verification, and its limits

Both response formats confirmed against the live API. The error-handling
logic was tested over quoted errors, bare and old-style invalid-appid, a
quoted genuine answer and a plain answer — 8/8, including the interaction with
sorryDave.

Not yet run on real hardware against AmiSSL httpget. My board runs under
Amiberry with bsdsocket_emu, and whether AmiSSL's TLS works over emulated
sockets is still an open question on my end. The transport indirection and the
error-string fixes are independent of that, but I did not want to claim an
end-to-end pass I have not seen. Happy to report back once I have.

No configuration of mine is included; g.appId remains yourappidhere.