Allow mobile users to tap the prompt line to focus the input box

[dfabulich]

Fixes #53

I guess strictly speaking it doesn't perfectly fix #53, because there's still no easy way for users to realize that they need to tap on that line to type, even with my PR #51, because the hint won't be visible. But at least it will be possible to open the keyboard, if you can guess to click on the last line, which is way better than what we have now.

(If we cared about this, we could add some special styling to the input line, e.g. turn it blue or something…?)

[dfabulich]

I added another commit to allow the input to wrap to the next line if the prompt is too long. Together with my "Tap here to type" PR, it solves #53 completely.

[erkyrath]

I've merged in the input element changes. (Remove position:absolute; minimum width 200.)

The "Tap to type" placeholder is also in.

The click-inputel-to-focus handler causes problems. It sticks around forever, for a start. (Surprising if you click on a prompt in the scrollback.) It also interferes with legitimate operations like selecting the prompt text. (E.g., if the player wants to copy "Have you played interactive fiction before?" to the clipboard.)

I think the combination of the wider inputel and the placeholder is adequate for our needs.

(There's still an issue with char input in the status window -- c.f. I6 menu behavior. In that case, the inputel is still narrow. It shows a one-character placeholder, but that's pretty weaksauce.)

[erkyrath]

The de-absolutization makes for one visual bug: if you narrow the window, the cursor (I mean, the text insertion point) briefly gets shoved down to the next line. It comes back on the next rearrange event, but it's still a bit ugly.

Maybe we want it absolute except when the min=200 bound has been applied.

[curiousdannii]

I used the flex system to auto-expand the input. But it was quite complex to get it to work with multi-word prompts (I ended up making each word its own <span>.)

[erkyrath]

Maybe we want it absolute except when the min=200 bound has been applied.

I got this to work, although the calculation is a bit messier than it used to be. (Requires using a span containing a ZWJ character as a measurement device. Sigh.)

But it doesn't require messing with the existing prompt text, so I'm going to stick with this solution.

While digging around, I realized that the logic for reusing the input element doesn't work, and probably never worked. We are creating a new input element every turn. But browsers seem fine with that and don't flicker the keyboard, now that we've gotten rid of the old deferfunc() delay on focus.