Protect headers we always send from override

The extensibility is not great because execline makes lists difficult.
There are no native lists, not to mention any kind of list.contains

httpd.execline: fix: typo; s6-test deprecation

The latter is a partial fix

Implement Content-Type override

Document accordingly

Ignore any Content-Type headers in
`configuration/override/${resource}/headers`

* Remove empty line comments

Content-Type_table: fix: JS; charsets

correct reference to http-print-header-files.execline

http-header-parse.execline: convert parsed header names to lowercase

Update all lookups for what is now called httpd_header_parse_host

* Fix accidental whitespace errors

httpd-print-header-file.execline: rename; fix

fix: preserve user configuration for logger on `git pull`

http-print-header-file.execline: improve documentation

in addition, rename this script for accuracy

Update README

allow less specific headers to take effect

allow headers to refer to requested hostname, resource

also document this fact

uncomment a line from README

fix: correct errors in README

additionally, update it

improve logger output for processing

bugfix: respond for any sytactically valid Hosts

as a fallback, make sure to send a response even when invalid
hostnames are required

adjust hiding client input to satisfy toybox

when done reading from the client, we defensively close stdin, to
prevent potential bugs being exploitable to malicious input

toybox opens /dev/null if stdin does not exist, which crashes in a
chrooted evironment. piping in an empty string more or less
accomplishes the same thing as closing stdin would

i really do not know why toybox found this necessary.

change example content type for Market Commons

per https://github.com/marrus-sh/MarketCommons2-Ecmascript#miscellaneous

http-error-response.execline: cleanup

add notes/warning on external contributions

change license

bugfix: unbreak response when no extra headers

use more sensible default values

update for breaking changes in execline

+ `backtick -i` is now the default behaviour
+ `backtick -I` is now the old default behaviour
+ `backtick -x` is now what `-I` used to be
+ `backtick -E` was added to automatically `import -i -u`
+ `trap` no longer supports timeouts; switch to timeout(1p)

allow configuring domain-name–agnostic error response pages

additionally, remove outdated comments.

remove unused debugging line

http-get-extra-headers.execline: bugfix: terminate headers with \r\n

embarrassing.

update README for changes

note the TODO about error status pages. how did i forget that???

reorganize configuration of resource- and domain-specific headers

in doing so, move so-called ”extra headers” code to a separate script

furthermore, slightly adjust the logic of http-error-response.execline

headers are now specified on a per-header basis, one file per header

begin making visible-to-httpd/configuration/overrides generic

isolate chroot-exclusive contents

also rename several folders in anticipation of further restructuring

as a bonus, `supported-hostname-test.execline` no longer needs special cases

introduce custom HTTP status pages [NEEDS WORK]

as an additional bonus, child processes of `httpd.execline` now inherit
the environment variables for the parsed start line and headers; this
allows `http-error-response.execline` to make use of the host supplied
by the client request with minimal changes.

note that `Content-Length` is currently not supplied anymore for header
responses (functional, but the HTTP/1.1 standard says you “SHOULD” use
that header); this needs fixing.

also note that `http-error-response.execline` currently forces error
status pages to use a `Content-Type` of
`application/xhtml+xml; charset=utf-8`; surely we should allow the user
to override this. (perhaps make status code *folders*, and use
constituent files `Content-Type`, perhaps `extra_headers`, and of course
`message_body`, in that directory? this interface would be less than
ideal though)

initial commit