[Spec] Custom Note Types

[codello]

Suggestion

Currently the spec includes the following

format/spec.md

Lines 793 to 796 in eaebb36

	The note type indicates how singing the correct or wrong note should affect scoring.
	The following sections define standard note types.
	Implementations MAY substitute unknown note types with freestyle notes (`F`).
	Implementations MUST NOT attach semantics to note types not covered by this specification.

I'd like to suggest the following changes:

1. Clarify that applications MUST ignore unknown note types.
2. Allow applications to use custom note types not covered by the spec.

Use case

1. I think this is very important for forward-compatibility. If at some point we want to introduce a new note type this would require a major revision of the file format otherwise.
2. The reasoning is similar to [Spec] Application Specific Headers #56: I expect that at some point the need for a new note type will arise in some application. I'd like to have a defined strategy for these cases rather than risking multiple applications implementing conflicting behaviors.

Extra info/examples/attachments

1. One detail about ignoring unknown note types is that new note types might need new syntax elements. Currently all notes follow the same pattern of X <start> <duration> <pitch> text. Should this format be required for unknown note types as well? Or should any line be ignored that starts with an unknown character followed by a space?
2. I think we should reserve certain characters for future standard note types but I'm unsure which ones. If we want to limit the note type to a single byte, maybe we use standard ASCII (up to 0x7F) for standard note types and allow 0x80 to 0xFF to be used for custom note types?

Alternatives Considered

1. It could be simpler to just do a major revision of the file format for new note types. I don't expect this to come up on a regular basis. Then implementations could reject unknown note types. However, major revisions have a high risk of not being adopted or being adopted very slowly making it very difficult for song creators to use new note types (or they would have to create 2 versions of the song in different file format revisions).
2. A single byte for the note type is pretty limiting in terms of namespacing. If for example custom note types were prefixed by some character or string it would make it easier for implementations to use custom note types. However, I think this would potentially break current implementations. This would be a possible approach for v2 of the file format.