There might be a rough edge or two here to be smoothed out later, but this is a solid first pass.

… is running

It turns out that hardware MIDI devices are even less happy about this than the stock ToneJS Piano code, and will enter an endless loop of pedal up/down actions if sent consecutive alternative pedal up/down events without any time between them -- as is done in the SamplePlayer to silence all held/sustained notes immediately upon Pause or Rewind. Fortunately the MIDI devices I've tested sound fine on Pause or Rewind when the pedal up/down trick is not used -- in this respect as in many others, they are better performers than the ToneJS Piano.

This allows notifications about the availability of external MIDI connections (or lack thereof), the majority of which are generated just as the app is initialized, to remain on screen long enough to be read. Presumably the purpose of the `clearNotification()` call in `resetApp()` is to clear any lingering error messages from previous rolls, so it's OK not to do it when the app first runs. Note that there's still a potential problem whereby the MIDI status notifications can pile up all at once so that it's still difficult to read any of them before they disappear, but this can be handled in a subsequent update.

There may be more elegant ways to do some of this. Destroying the <WebMidi/> component when it's not in use seems clean, although there is the minor issue of the `midi.onstatechange` handler sticking around. In any case, the checkbox renders some of the previous notifications unnecessary, and it kind of makes sense not to show the checkbox at all if Web MIDI isn't supported in the browser -- though I kind of liked the "too bad your browser can't do this" popup in the previous commits.

…of-bounds note_on velocities

…to WebMIDI devices

…ionality."

This reverts commit 02653fa.

This exposes the **actual** issue with the `<Notification/>` component, which is that it's a singleton and is being clobbered.  Will fix in due course.

This isn't what it should look like, where it should go, or even how it should behave (entirely).  Other than that, it's a good commit... :)

It shouldn't be the job of the `<WebMidi/>` component to manage this.

However, this does affect the way the `<Keyboard/>` component (the other client for these functions) works a little -- clicking the keys now removes the `depressed` class if it was previously applied (i.e. if the roll player state is in the middle of (a) note(s)).  This is in line with the behaviour when using the keys on a WebMIDI-connected device.

If this is considered undesirable (and I think I'd lean that way, if not perhaps all that hard), then both the on-screen keyboard and WebMIDI-connected devices could could be decoupled from `$activeNotes`, but I'd rather do that with a argument to the `startNote()` and `stopNote()` functions (similar to the `fromMidi` argument).

This is some opinionated stylistic refactoring.  The main changes introduce more destructuring and switch statements (which are technically faster, but the point here is more about readability).  I think I can make the case that all of these changes are in line with modern best practices, but I'm happy to entertain counter arguments :)

Destroying and re-mounting the right sidebar (in particular) when the roll is changed can cause problems if child components aren't destroyed properly due to outro transitions (see sveltejs/svelte#5268).  This has caused a number of bugs with the `<RollViewer/>` component not being recreated properly.

One option is to eschew all outro transitions in other parts of the app; but I think a better solution in this specific case is to avoid destroying and recreating this part of the component tree unless absolutely necessary.

This is a little nicer when enabling/disabling WebMIDI.

Pedal events send to external MIDI devices can be re-emitted back to the app (under at least some circumstances), causing feedback loops.  With this commit, external pedal events are ignored unless explicitly enabled, in which case "app-side" pedal events are disabled instead.