test_record: Check that the screenshots were saved to disk

`stbt record` saves screenshots to disk each time the user presses a
remote control button. Now the unit test actually checks that those
screenshots are being saved to disk.
stbt record: Simplify logic in `record` function

This is mostly a refactoring, though there is one user-visible change:
The numbering of the saved images now starts from 1 instead of 0. This
isn't significant though: it won't affect existing scripts, and new
scripts will work too.

The motivation for this, in addition to making the code clearer and
shorter, is to allow the next commit (which see).

Why do we need two nested `try` statements? We want to take one final
screenshot on `KeyboardInterrupt` (when the user presses Control-C), or
if the `remote_input` iteration ends (when using
`--control-recorder=file:///dev/stdin` and the user presses Control-D).
But we don't want the `except KeyboardInterrupt` block to take another
screenshot if the user pressed Control-C during the
`write_wait_for_match` triggered from `remote_input` iteration ending.
I'll be able to eliminate the outer `try` in the next commit.
stbt record: Avoid explicit `del`

Commit 47c56330 added the line `del remote_input` so that the destructor
of the `remote_input` iterator (i.e. `stbt-control.main_loop`) is run
(including the `curses` cleanup in the `terminal` context manager of
`stbt-control`, which clears the screen) *before* any unhandled
exception backtraces are printed to the terminal.

This current commit avoids the explicit `del` by not holding any
references to the `stbt-control.main_loop` iterator; if an exception is
raised in `record` (e.g. from `stbt.get_frame` or `stbt.press`) then the
`stbt-control.main_loop` iterator is destroyed as soon as the exception
leaves the `record` stack frame. (This of course relies on CPython's
deterministic destruction, but so did the previous solution with the
explicit `del`; `del` only decrements a reference count.)

Specifically, `remote_input` was a local variable inside the `record`
function. The raised exception contains a reference to each frame on the
stack, and the frame for the `record` function contained a reference to
`remote_input`, so `remote_input` wasn't destroyed until the exception
object itself was destroyed.
stbt record: Fail early if no video is available

For example, if the user's `source_pipeline` configuration is incorrect,
or if the system under test is switched off.

Without this, `stbt record` waits for the user to have entered *two*
button-presses, then silently waits 10 seconds (for `get_frame` to raise
`NoVideo`) before exiting. Now it still takes 10 seconds to fail, but
that happens at the beginning; when there *is* video it won't delay for
10 seconds, only as long as it needs to find video. If you're using
`--control_recorder=stbt-control` you won't see the prompt for input
until video is established.

I don't want to reduce the default 10 second timeout because some video
capture devices can take several seconds to start delivering video,
especially if they haven't been "warmed up" by a recent capture.