Communicating memory pressure in mediastream recording

Another implementation issue that may be useful to surface in the API:

In the record(timeslice) case, the implementation will probably not want to
incur the latency penalty of writing each intermediate block to disk before
creating the blob handle. This means some coordination is required to make
sure the app doesn't let too much in-memory content accumulate. (The
no-timeslice overload shouldn't have this weakness.)

There's already a channel for communicating this kind of pressure with the
onerror/onwarning event handlers. The ondataavailable event is the trigger
for it, and there's already an OUT_OF_MEMORY error that can be used for
failure if the implementation has to start dropping slices or take some
other remedy. Should there be a LOW_MEMORY warning enum value to indicate
to the app that if it's waiting around to delete intermediate memory it
should do so immediately?

To reinforce this coordination, would it be helpful to have
record(timeslice) also take an onerror handler to help make sure app
developers are accounting for the increased coordination effort they'll
need to have to use the API successfully?

-Greg