Async constructors for MidiInput and MidiOutput to support WebMIDI

[jhartquist]

Relates a bit to #47 and #48

Motivation

When using the webmidi backend, the browser requires async initialization for the MidiInput and MidiOutput objects. When using MidiInput::new and MidiOutput::new and then immediately querying the ports, none will be available until the call to requestMidiAccess resolves.

In the existing browser example, a loop is set up to poll until devices are available, but this makes it difficult to distinguish between the case where there are actually no devices, or if they just haven't resolved yet.

Changes

• Added new_async methods to both MidiInput and MidiOutput
  • they fall back to new method in all backends except for webmidi
• Added browser examples for the async cases and one similar to the test_play example to test output
• Simplified the loading of WASM in index.html due to browser support of JS modules
• Added instructions for building & running the browser examples
• Updated the azure WASM test to point to the read_input_async example

Notes

• Opening ports is also asynchronous, but the current implementation works fine for my use case, so I didn't make any changes for that in this PR.
• The new_async methods could be put behind a feature flag (there's an added dependency in the webmidi case for wasm_bindgen_futures, however I believe most people would find the async version more usable than the sync version when targeting the web. Would love to hear what others think about this.
• May want to create tests for each of the 3 WASM examples (currently only one)

Let me know if you have any questions or suggested changes. Thanks for the awesome work on this crate!

[Boddlnagg]

Sorry, this fell through the cracks, and it's a lot of code ... are you still interested in pushing this forward?
The hard question here is if any other platform can benefit from true async support (which would then potentially influence API design) ...