[MIDI]: collapsing MIDIMessage into MIDIEvent

We have an open spec bug on whether we should get rid of the MIDIMessage
type altogether (https://www.w3.org/Bugs/Public/show_bug.cgi?id=19975).  In
order to think through and demonstrate how this would work, I made a
prototype copy of the spec with MIDIMessage collapsed into MIDIEvent, and
checked it in alongside the current spec.

The prototype is here:
https://dvcs.w3.org/hg/audio/raw-file/tip/midi/specification-no-message.html.
The current spec is here:
https://dvcs.w3.org/hg/audio/raw-file/tip/midi/specification.html.

Pros for collapsing MIDIMessage into MIDIEvent:
- Simpler; fewer interfaces and objects.
- Some underlying platforms (Windows, in particular), will only ever
deliver one MIDI message at a time; this makes it likely that the
MIDIMessage array in MIDIEvent superfluous (there will only ever be one
member of the array), and leads to the possibility of app code being
created on those platforms that just dereferences messages[0] and ignores
its length.
- Web app code doesn't need a loop going through the array, when typically
only a single message will be delivered at once.

Pros for keeping MIDIMessage separate, and MIDIEvent referencing an array
of MIDIMessages:
- Some underlying platforms (CoreMIDI, e.g.) _may_ deliver multiple
messages in one call, with separate timestamps.  This would enable those
messages (after being sorted into valid MIDI messages; CoreMIDI doesn't do
that) to be passed to a single call to the Web MIDI onmessage event
handler, rather than having to call the onmessage handler once for each
valid MIDI message.  (Note the call time for this is expected to be quite
low - more details in the bug comments - but certainly, wrapping into one
call would be at least very slightly more performant in those cases when
that can be done.)

Comments appreciated.  Olivier suggested that perhaps we could put this
issue on the agenda for the 5 December telecon if we don't resolve it in
email prior; that seems like a good idea to me.

-Chris

(Note this temporary prototype spec also includes the removal of the
'fingerprint' attribute on MIDIPort: this is an orthogonal issue, but I
wanted to think through that as well.)