Handle short midi input messages with final data byte of 0

Hey there! I was experiencing a bug with some basic midi-eye code on jruby, where note-offs after the first one have their notes inaccurate. For example, running this code:

```ruby
#input = UniMIDI::Input.first
input = UniMIDI::Input.gets
midiin = MIDIEye::Listener.new(input)

midiin.listen_for do |event|
    puts event[:message].verbose_name
end

midiin.run(:background => true)
```
and pressing and releasing C5 5 times results in:

```
Select a MIDI input...
0) Bus 1
1) Midi Touch
2) Port 1
3) Port 2
8) Real Time Sequencer
> 2
Note On: C5
Note On: C5
Note On: C#5
Note On: C5
Note On: Gb4
Note On: C5
Note On: A4
Note On: C5
Note On: B5
```
Because it only happened after the first message, I figured it was something to do with the slicing of the midi messages, and after some digging, it seems like when the velocity is zero for a message,

```ruby
s = msg.to_s(16)
```
results in :data that has only two elements, as in ```[{:data=>[144, 72], :timestamp=>1351.9999980926514}]```

Padding the msg from Java with leading zeros (```.rjust(6,"0")```) seems to fix the problem for me:
```
Select a MIDI input...
0) Bus 1
1) Midi Touch
2) Port 1
3) Port 2
8) Real Time Sequencer
> 2
Note On: C5
Note On: C5
Note On: C5
Note On: C5
Note On: C5
Note On: C5
Note On: C5
Note On: C5
Note On: C5
Note On: C5
```

I think 6 characters should be good since it seems like ```unpack``` is only called with short midi messages. I must confess to being new to MIDI, Ruby, open source, and to your wonderful libraries, so I was unable to determine the test data to enter into the tests to make sure the library still functions with this change. If this fix is off-base, at least it can hopefully start you thinking about the problem. Thanks so much!
truth