docs: A demo recording in the README

[kimsun721]

A demo recording in the README

Why

The README described the server but showed nothing running. A visitor had to
run it to see that it works.

Changes

Demo recording

A 20 second recording sits at the top of both READMEs. OBS publishes four
simulcast layers at 60 fps and the watch page plays them: automatic mode first,
then the viewer switches to the lowest layer and back to the highest. The
broadcast shows a millisecond clock and the page overlays its own, so the delay
can be read off any frame.

Two things differ from the issue:

• Only the watch page is recorded, not OBS beside it. Both clocks are already
  on the page.
• It is an animated WebP, not a GIF. It plays inline the same way, at 0.6 MB
  against about 3 MB for a GIF at half the frame rate. GitHub strips <video>
  from a README, so an mp4 in the repository cannot be embedded.

Layer bitrate without filler data

Found while recording: the layer buttons read 6001 kbps while the viewer was
receiving 1.7 Mbps.

OBS in constant bitrate mode pads H264 with filler data. The server measured a
layer by the length of each received frame, filler included, but str0m drops
filler when it packetizes a frame for a viewer. Automatic layer selection and
the relay cutoff were therefore judging layers by a bitrate no viewer is sent.

A layer is now measured by what will be sent. An H264 frame goes through
str0m's own packetizer and the sizes of the resulting packets are summed, which
needs str0m's unversioned feature. Other codecs are measured as before.

Tested

With OBS in constant bitrate mode, top layer at 1080p:

	Layer button	Received by the viewer
Before	6001 kbps	1.71 Mbps
After	1759 kbps	1.76 Mbps

The integration test for layer measurement only checked that layers rank by
bitrate, which a count of packets would also pass. It now checks that each
figure is within 25 percent of what the publisher sends. The test publisher
does not send H264, so the H264 path is covered by the OBS run above.

Closes #76