Update https://w3c.github.io/mediacapture-record/#dom-blobeventinit-timecode.

The spec text was unclear. From offline discussion with the original spec author
it's believed that the intent of the spec language was meant to convey
that the first produced timecode would contain an absolute timestamp. However,
it's not clear what usecase is unlocked by that, as the user can construct
their own absolute timestamp with performance.now() on event reception. This
ignores the fact that the event handler can execute delayed, but since it's
not clear what problem this fixes, this PR simply makes the timestamp sequence
start with zero instead.

Fixes #222.

Author: handellm

MediaRecorder.bs

@@ -680,10 +680,11 @@ enum RecordingState {
   encoding of the blob data.
 
   <dt><dfn attribute for="BlobEvent"><code>timecode</code></dfn></dt>
-  <dd>The difference between the timestamp of the first chunk in
-  {{BlobEvent/data}} and the timestamp of the first chunk in the first
-  {{BlobEvent}} produced by this recorder as a {{DOMHighResTimeStamp}} [[!HR-TIME]].  Note that the {{BlobEvent/timecode}}
-  in the first produced {{BlobEvent}} does not need to be zero.
+  <dd>For a MediaRecorder instance, the {{BlobEvent/timecode}} in the first
+  produced {{BlobEvent}} contains 0. Subsequent {{BlobEvent}}'s
+  {{BlobEvent/timecode}} contain the difference of the timestamp of creation of
+  the first chunk in said {{BlobEvent}} and the timestamp of the first chunk of the
+  first produced {{BlobEvent}}, as {{DOMHighResTimeStamp}} [[!HR-TIME]].
   </dd>
 
 </dl>