html speech web api changes

Here's the latest version of the speech api.

Changes made based on http://www.w3.org/2011/10/13-htmlspeech-minutes.html

Section 7.1: Added the default values for language, including not set
for getting, but set to the correct value for reco service.

Section 7.3: Clarified that the end event is always fired, not just in
response to aborts.

Section 7 and 7.1: Added a method to do text based interpretation and
the explanation


>From the to do list:

Section 7:  change the set methods to attributes [this was mostly
straight forward, but sometimes not, more information follows]:

Done:
- maxnbest
- language (note I changed from ISO language to BCP 47 to match the
HTML 5 language)
- saveforrereco
- endpointdetection
- finalizebeforeend
- interimresults
- confidencethreshold
- sensitivity
- speedvsaccuracy
- completetimeout (This was a unitless integer with no explanation, so
I made it be milliseconds)
- incompletetimeout (This was a unitless integer with no explanation,
so I made it be milliseconds)
- maxspeechtimeout (This was a unitless integer with no explanation,
so I made it be milliseconds)
- inputwaveformURI

Not done because too complicated to do without checking back with the
group: grammar and customparameter

Grammar and customparameter are more complicated because it isn't a
straightforward unit but rather a structure we are setting.  With
grammar there are URI, weight, and modal as a triple (although weight
and modal are optional).  With customparameter there is a name and a
value pair.  I think it would make the most sense to create small
structures for each of these and then make the attribute of the
SpeechInputRequest be an array of these structures.  That would
complete the conversion of methods into attributes.  However, I'm not
sure that this is then the most usable way for a developer.  It is
good that the internal structure is there if they want to read it, or
even modify it, directly (like they are building a grammar list -
possibly in code that is distributed through out the application - and
have added 6 grammars already, and now want to look back at what has
been added) but it might make sense for these structure based
attributes to leave the methods available as a syntactic sugar that is
easier to use.  Thus we might have all of:

[Constructor]
interface SpeechParameters {
    DOMString name;
    DOMString value;
};

and then in the SpeechInputRequest still have:

void setCustomParameters(in DOMString name, in DOMString value);
SpeechParameters[] customParameters;

And likewise for grammars.  Does that sound appropriate to folks?


Still on the to do list:

Everywhere: proofread to set camelCase consistently throughout
I started to do this but wasn't sure what, if anything, should be
camelCase or AllCapCase or alllowercase.  Looking at HTML for our
guide I see combinations of case in a number of places.  In events,
you have mouseleave, dblclick, DOMFocusIn, DOMNodeInsertedIntoDocument
from http://www.w3.org/TR/DOM-Level-3-Events/ which is basically all
lower case except DOM events which are mixed.  In HTML all attributes
are all lowercase in general (although case doesn't matter in the
names of tags and attributes in HTML generally).  If I look at the
File API from http://www.w3.org/TR/FileAPI/ I see attributes are
generally camel case (contentType, readyState, lastModifiedDate) but
not the attributes for the event handlers (onloadstart, onabort) but
camel case for methods as well (readAsBinaryString, readAsDataURL).
And the interfaces are AllCaps (like FileReader or our
SpeechInputResult). WebAudio from
https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html
uses nearly always camel case for everything but the interfaces which
are again AllCaps.  The exception is for onaudioprocess which is an
eventlistener.
So is it safe to say we want interface objects in AllCaps, all methods
and attributes in camelCase except for the oneventfoo attributes which
should be all lowercase?

Everywhere:  Renumber sections now that some sections have been removed.

?: add speech-x event information for non-standard custom events (I.e.,  visime)