[TODO]: Make WinMM and WinRT MIDI 1.0 resilient to midisrv restarts for apps/services with open sessions

This came up due to the Lemur product which has two long-running services. They connect to WinMM when they start, which then causes the MIDI Session to be created with the service. No ports are opened for some time, but the session was created on load.

If the MIDI Service is restarted while these services are running, the registered session goes away, and any calls to open ports fail. Without the session logic, the port opening would usually succeed, even with completely re-enumerated ports.

Normally, for an app, we would just require the app to be restarted when the service is restarted. But that is more complex for other services, and we cannot expect a customer to manually restart various services.

Possible solution

• If a WinMM port open fails due to a missing session, automatically re-created it. It's reasonably safe to assume in the WinMM case that this is due to a service restart.
• If the error codes aren't fine-grained enough to know the problem is a missing session, then check for a valid session before opening any WinMM port

Anti-solution

• Do not want to automatically create missing sessions in the service itself due to the lifetime of session objects in the Windows.Devices.Midi2 API, and the potential to get out of sync with the service.

Developer Guidance

• For any MIDI-using services, have them register a service dependency on midisrv. This is good guidance anyway for anything that expects MIDI to be running (virtual device services, NI integration service, Lemur Daemon, others)
  sc config <service_name> depend=midisrv

Also todo: Check to see if this similarly impacts WinRT MIDI 1.0, and apply same WinMM approach there if so.