HTTPD404E names the ignored CONFIG= parm, so every fatal config error ends with "processing (null)"

[mgrossmann]

src/httpd.c:95:

rc = http_config(httpd, config);
if (rc) {
    wtof("HTTPD404E Errors occured processing %s", config ? config : "(null)");

config comes from the PARM= string, but http_config() has ignored it since
the Parmlib migration:

(void)member;   /* CONFIG= parm ignored -- we always read DD:HTTPPRM */

So the one message an operator gets naming what failed to process names
nothing. Observed while testing #164 — every fatal config error ends with:

HTTPD420E Route authorization policy incomplete -- HTTPD will not start
HTTPD404E Errors occured processing (null)

It is not misleading in isolation (the messages above it name the offending
route or the bind failure), but it is dead text where the useful fact belongs.
The real identity of the configuration is the HTTPPRM DD, and the STC PROC
makes it a startup choice:

//HTTPD    PROC M=HTTPPRM0,
//            D='SYS2.PARMLIB'
//HTTPPRM  DD  DSN=&D(&M),DISP=SHR,FREE=CLOSE

S HTTPD,M=HTTPPRM1 is a documented way to start, so "which member did this
server just fail on" is a question an operator can really have — and the answer
is knowable: the DD's DSN and member can be read from the JFCB (RDJFCB) or
fldata() on the open FILE.

Options, in ascending order of effort:

1. Drop the operand: HTTPD404E Errors occured processing the configuration.
2. Name the DD: ... processing DD:HTTPPRM.
3. Name the actual member: ... processing SYS2.PARMLIB(HTTPPRM0) — the useful
   one, and it would also make the successful startup path worth a matching
   HTTPDnnnI naming the member that was read.

Also worth deciding whether the CONFIG= PARM should be removed outright or
made to select the member, since today it is accepted and silently ignored.

[mgrossmann]

Fixed in #168 (3e612fe), auto-closed by the merge. parmlib_name() resolves the DD's real target from DSAB → TIOT entry → JFCB, so the member is named before parsing (HTTPD022I Configuration from SYS2.PARMLIB(HTTPPRM0)) and HTTPD404E drops the operand. Verified live with two different members via S HTTPD,M=, which is what proves the walk reads the live allocation rather than a default.

On the open question — neither remove CONFIG= nor make it select the member: S HTTPD,M=member already is the MVS-native selector, and removing the parse would leave a leftover parm as silently ineffective as it is today, which is the actual problem. HTTPD024W now says it did nothing and names the mechanism that does; migration.md shows what it looks like next to the instruction to remove it.