Attempt to fix invalid loop info when loading a new song

[PhoenixBound]

As mentioned in #31, it's fairly easy to trick ebmused into saving an invalid song file that has bad loop data that goes past the header. It should be easy to detect this case and autofix it so that the "Loop To" field can be set to a valid index. This would avoid the need to hex-edit the song to recover it.

Ideally the user would be warned about this happening when the song is loaded/decompiled, and ebmused would mark the pack as modified/unsaved.

Initial sketch of implementation, without looking into it much:

• Make it possible for decompile_song to tell its callers about three states reliably: "success with no warnings," "success with warnings," and "failure/error"
  • Modify decompile_song to consistently set decomp_error = NULL; in the success case. This means success can be identified when song order length != 0 and decomp_error == NULL
  • Make it set decomp_error = "Corrected bad loop info"; in the "success but the song header was invalid" case. This means "success with warnings" can be identified when song order length != 0 and decomp_error is non-NULL
• Modify callers to check for the "success with warnings" case and display a message box
  • import_spc should be pretty simple to insert an if statement into
  • There are considerably more callers of decompile_song via select_block and other packs.c methods that call it internally. It's important to check how amenable each of them are to bubbling up errors/warnings to the UI

Other things to check:

• Do any callers assume that pack data won't be modified by decompile_song? The proposed changes would involve decompile_song mutating stuff from under them
• Unsure of the status of Ebmused GTK port #69, but this would involve making the message box appear for a theoretical GTK/otherwise rewritten version of ebmused, too.