`MIDIFile`: Add structure validation

[orchetect]

Motivation

MIDIFile allows for a fair degree of freedom with how its contents are constructed. Reliance on reading the documentation is necessary to understand and apply certain conventions.

This may lead to conditions where its structure does not cause errors, but it is technically illegal in terms of MIDI File Spec convention.

Some of these conditions are minor - other 3rd-party MIDI software or libraries/parsers may slacken their error conditions to allow for them. But some of these conditions are more undesirable and may produce incompatibilities with 3rd-party software.

For example:

• It is possible to set the MIDIFile format to Type 0, which technically requires exactly 1 track chunk - no more, and no less. However many parsers will allow multiple tracks and ignore the format and treat it as Type 1 (synchronous multitrack) in this case.
• In a Type 1 format file, tempo and time signature events are expected to be exclusively within the first track, but it is possible to insert them on multiple tracks
• It is possible to insert multiple MIDI events on a track that should only be used once, such as SMPTE offset for example
• It is possible to insert MIDI events at any time offset on a track that are conventionally expected to be at time 0, such as Track Name or SMPTE offset for example

Proposal

These actions are not prevented, and are not error conditions in of themselves. One such reason is that it allows parsing MIDI files that contain such illegalities while preserving the data in tact and not aborting file parsing - in such a case, the file's data itself is not malformed but the event definitions may be in a logical ordering that is unexpected or non-standard.

It could be beneficial to have an added validation method on MIDIFile to heuristically analyze the model contents and compile a list of warnings and/or recommendations based on all known conventions. This is a separate concept from parsing errors which are generally unrecoverable. But some parsing errors (such as a Type 0 file with more than 1 track) could be converted to a validation warning and not a fatal error condition.

This could serve both the purpose of educating the developer who is using MIDIKit during development of their software to diagnose issues, as well as provide somewhat granular information that could be actionable or presentable to the user in a user interface to inform them that data in the MIDI file may not be properly structured.