[3.0] Theme split (wave 4, part 11) — describe the posting form's checkboxes instead of writing them out

[albertlast]

Description

Part of the #7933 split (wave 4, part 11). Posting area, and the first of two
slices that are small enough to stand on their own.

The eight checkboxes under the editor were eight ternaries concatenating HTML
inside the template. Post::setupPostOptions() now describes them as data and
template_post_options() draws them, and the collapsible wrapper becomes a
<details> element instead of an smc_Toggle and its generated script.

A bug falls out of it. "Move this topic" carried a stray quote:

value="1"' . (!empty(Utils::$context['move']) ? ' checked" ' : '') . '>

so it emitted an attribute called checked" and the box never came up ticked,
even when you reached the form through a link asking for it:

	release-3.0	this branch
rendered	<input … value="1" checked"="">	<input … value="1" checked="">
.checked	false	true
submitted	(nothing)	move=1

Hidden "off" fields. An unticked checkbox submits nothing at all, so
anything that can be switched back off needs a hidden field of the same name
carrying the zero ahead of it. That is what 'hidden' is for in each entry, and
it is why notify=0, lock=0, sticky=0 and move=0 are listed explicitly
rather than left out.

On <details>. It drops the smc_Toggle call and about 25 lines of
generated script, and the disclosure triangle then works with a keyboard and
without JavaScript. The small listener that is left only copies the open state
into the additional_options field, so the next form comes back the same way
round. The list itself is a two column grid rather than two floated columns, so
the RTL and narrow screen rules that undid the floats are gone too. While it was
there, #post_additional_options .progress_bar went as well: the attachment
progress bars it names sit above that wrapper, never inside it.

Naming. #7933 renders this list as <ul id="additional_options">, which
collides with the hidden <input id="additional_options"> further down the same
form. The <ul> comes first in document order, so getElementById returns it
and the open state stops persisting. It is #post_options here instead. Worth
aligning when the rest of that branch lands.

Testing

The whole posting form was serialised on release-3.0 and on this branch for a
new topic, a reply, a modify and a move. The submitted names and values are
identical apart from seqnum, which is per request, and move=1, which is the
bug above. Toggling the details element was checked to move the hidden field
between 1 and 0, and to leave the list hidden when closed.

Issues References (Fixes|Related|Closes)

Related to #7933