drop() no longer calls midiOutReset

[dwmuller]

Fixes #122

On Windows using the winmm backend, midiOutReset was being called before midiOutClose, presumably to cancel any pending output. This caused extra MIDI commands to be sent. Instead, we now call midiOutClose repeatedly until it's no longer blocked by pending output.

Tested it in a very simple application, monitoring MIDI activity using "BC Manager", which is also how I verified the original problem. No extraneous MIDI is being sent now.

[dwmuller]

FWIW, I also tried my app with midir's winrt backend. Works fine, and does not suffer the same problem that I saw with winmm. Although the MIDI port names are different in RT vs MM. The names that WinMM sees are more reasonable.

[Boddlnagg]

Thanks for the PR (and sorry that it took me so long to respond)! It looks good to me, except for the potential endless loop ... is there any guarantee that midiOutClose will not return MIDIERR_STILLPLAYING "forever"?. I would feel more comfortable with a solution that retries midiOutClose maybe once or twice and eventually falls back to midiOutReset, since midiOutReset is even explicitly mentioned on the documentation for midiOutClose. Could you try if that alternative would also work for you?