Fix misc. warnings in MikMod reported by GCC 12.2.1

[AliceLR]

Please CAREFULLY review and test these warning fixes for the MikMod player. They seem fine to me and I encountered no issues in the affected parts of the UI.

• display.c:144: buffers were too short to fit the full precision of two ints. Doesn't matter in practice, but it costs nothing to make these slightly bigger.
• display.c:392: bounding using strlen(...) + strlen(...) confused GCC into somehow thinking the two fields could be long enough to cause truncation. Replacing these with archivelen, filelen, and moving filelen to the right side of the compare seems to fix it.
• display.c:440: signed int subtraction of two unsigned bytes can result in a 4-byte long string, potentially causing truncation.
• display.c:968: tmpfmt was slightly too short for one of the sprintf format strings.
• marchive.c:280: strncpy warning should have been suppressed but wasn't.
• mconfedit.c:374: egregious usage of strcat/strncat.
• mwindow.c:612: bizarre bounding of strncpy length on the source string which is better suited to a function that doesn't suck (snprintf).

Side note: for affected old MSVCs and MINGWs without the stdio wrappers for snprintf, the macro SNPRINTF should probably have a safety wrapper. Same for HAVE_VSNPRINTF, but also the case when HAVE_VSNPRINTF isn't defined looks really bad.

[sezero]

marchive.c:280: strncpy warning should have been suppressed but wasn't.

Two other uses of strncpy in filename2short versions at lines 252 and 281 need the same change.

mconfedit.c:374: egregious usage of strcat/strncat.

This gives me headaches, but should be OK I think

mwindow.c:612: bizarre bounding of strncpy length on the source string which is better suited to a function that doesn't suck (snprintf).

If msg is NULL, the result will be undefined behavior: https://stackoverflow.com/questions/11589342

[AliceLR]

Two other uses of strncpy in filename2short versions at lines 252 and 281 need the same change.

Done.

If msg is NULL, the result will be undefined behavior: https://stackoverflow.com/questions/11589342

I think the diff obfuscated this, but it is still guarded by if (msg) { ... }.

[sezero]

If msg is NULL, the result will be undefined behavior: https://stackoverflow.com/questions/11589342

I think the diff obfuscated this, but it is still guarded by if (msg) { ... }.

I was confused by the fact that there is no else case anymore but the code keeps calculating strlen(status_message) down below: but that is what the old code did, yes? In that case, I guess it's OK.

[sezero]

This is in now. Thanks.