Six Parmlib keywords the parser accepts are absent from configuration.md

[mgrossmann]

httpprm.c recognises 26 keywords. Six of them appear nowhere in
docs/configuration.md, so the only way to learn they exist is to read the
parser:

Keyword	What it does
UFS	UFS=0 skips filesystem initialisation entirely -- and with it HTTPD044W. installation.md names it; the configuration reference does not
CODEPAGE	CP037 (default), IBM1047 or LEGACY. Chooses the table http_etoa()/http_atoe() use
CLIENT_TIMEOUT_MSG
CLIENT_TIMEOUT_DUMP
CLIENT_STATS
CGI_CONTEXT_POINTERS

CODEPAGE is the one that needs prose rather than a table row, because its
scope is narrower than the name suggests and the boundary is invisible from the
member:

• It governs what cc370-compiled literals and MVS datasets are translated
  with. cc370 emits string literals in CP037 (common/src/mvs370.c,
  mvs_a2e_tab), which is why the default matches and why changing it is not
  free: under IBM1047 a [ compiled as 0xBA leaves the server as 0xDD,
  and every mvsMF array response stops being JSON. Measured against a live
  server: [ arrives as 0x5B today.
• It does not govern static files from UFS. http_send_file() translates
  those with the hard-coded IBM-1047 table (src/httpfile.c:70-71), matching
  what ufsd-utils and mvsMF's PUT /zosmf/restfiles/fs write. Measured
  end to end in Ship static/index.html as a UFS webroot image, uploaded with IND$FILE #252: the round trip is byte-exact, and only 0x85 and 0xF7
  fail to survive it.

Both halves are worth writing down: the first is a foot-gun, the second is the
reason a webroot image needs no codepage decision at all.

Found while shipping the webroot disk (#252, PR #253); no code change implied.