mothra-fixups: charset detection and a missing return in mothra

Two fixes to mothra(1), the web browser.

Source

    <https://9p.io/sources/extra/mothra/>

    mothra is not part of the 9legacy distribution.  It was dropped
    from the 4th edition when abaco replaced it and survives only
    under /sources/extra, so fetch it from there before applying
    this.  It builds against stock 9legacy libraries and carries its
    own libpanel; no system copy of libpanel exists.

    Fetch libpanel/pack.c by name.  It is served, but the generated
    directory index does not list it, while libpanel/mkfile lists
    pack.$O and plpack() is called from mothra.c, forms.c and three
    libpanel files -- so a tree taken from the index alone compiles
    and then fails to link.  The same index omits bootmgr.tgz, il.c
    and ip.il.h elsewhere in /sources/extra, all served fine.  Probe
    the URL rather than trusting the listing.

Runtime files

    mothra looks in /sys/lib/mothra, which 9legacy does not ship.

	start.html	the page it opens when given no url and no
			$url (mothra.c:253-257).  Without it, always
			pass a url.
	help.html	what the h and ? commands open.  Take this
			one from the source tree, not from the 2nd
			edition disc; the disc's copy is the 1995
			original and the shipped one is newer.
	display.pic	the screenshot help.html embeds.

    start.html and display.pic are in neither /sources/extra nor
    9legacy.  They survive on the Plan 9 2nd edition disc, under
    /sys/lib/mothra, which is the only place the runtime files still
    exist; mount that image to recover them.  None of this is needed
    to build or to browse with a url given on the command line.

rdhtml.c: recognise the character set

    plrdhtml looked for the character set in one place only, the
    older <meta http-equiv="Content-Type" content="...charset=...">,
    and compared the http-equiv value with strcmp.  HTML attribute
    values are not case sensitive, so a page writing Content-Type,
    which is the usual spelling, never matched and the page rendered
    as Latin-1.

    It also never looked at <meta charset=...>, the form HTML5
    introduced and the one most pages use now, so even a correctly
    spelled declaration went unread.

    Both forms are read now, with cistrcmp and cistrstr so the
    spelling does not matter, and utf8 is accepted alongside utf-8.

libpanel/draw.c: return a value from pl_boxsize

    pl_boxsize returns a Point through a switch with no default and
    no return after it, so control could fall off the end of a
    function that has to return something.  The switch does cover
    every state the enum declares, so no correct caller reaches it;
    this removes the undefined behaviour rather than a visible
    misbehaviour.

Apply

    cd /
    ape/patch -p0 < /n/contrib/mothra-fixups/mothra-fixups.diff

Rebuild

    cd /sys/src/cmd/mothra/libpanel && mk install
    cd /sys/src/cmd/mothra && mk install

Reverse

    cd /
    ape/patch -R -p0 < /n/contrib/mothra-fixups/mothra-fixups.diff

Not fixed

    Only utf-8 is recognised.  A page declaring any other character
    set is still read as Latin-1, which is what mothra did before.

    The character set in the HTTP Content-Type header is not
    consulted; only the meta element is.

    A charset parameter followed by another parameter, as in
    charset=utf-8; foo, is not read.  The value is taken to the end
    of the attribute.  Nothing in the wild appears to write it that
    way, and the older code had the same limit.