Throw error if data channel's buffer is filled, rather than closing.

Fixes #1148.

Option 2 for fixing the issue. The application doesn't need to know the
buffer's size ahead of time, because filling the buffer is no longer an
irrecoverable error. If it doesn't care about latency, an application
could send until an exception is thrown, then wait for the
"bufferedamountlow" event until it can send again, similar to a
non-blocking socket.

Note that this is deliberately different than how WebSockets work,
because the circumstances are slightly different: with WebSockets, it
was expected that applications had code to handle them being closed
unexpectedly. But this isn't true of WebRTC DataChannels, because before
an SCTP-level timeout can occur, the application would have done an ICE
restart and repaired the problem.

webrtc.html

@@ -8940,12 +8940,17 @@ <h2>Dictionary <dfn>RTCDataChannelInit</dfn> Members</h2>
           established yet, or if the <code><a>closing procedure</a></code> has
           started, then abort these steps.</p>
         </li>
+        <li>
+          <p>If the size of <var>data</var> exceeds the value of <code><a
+          data-link-for="RTCSctpTransport">maxMessageSize</a></code> on
+          <var>channel</var>'s associated <code>RTCSctpTransport</code>,
+          <a>throw</a> an <code>InvalidAccessError</code>.</p>
+        </li>
         <li>
           <p>Attempt to send <var>data</var> on <var>channel</var>'s
-          <a>underlying data transport</a>; if the data cannot be sent, e.g.
-          because it would need to be buffered but the buffer is full, the user
-          agent MUST abruptly <a>close</a> <var>channel</var>'s <a>underlying
-          data transport</a> <a>with an error</a>.</p>
+          <a>underlying data transport</a>. If the data cannot be sent, buffer
+          it, and if this is not possible because the buffer is full,
+          <a>throw</a> an <code>OperationError</code>.</p>
         </li>
       </ol>
       <div>