REQ: Reduce use of client killing error messages.

[dsvensson]

To slightly remove confusion about outdated clients that don't handle 1024x1024 textures, you can name a texture ezq_upgr_361 as this texture will be part of the message box that's the last thing the user sees of the ezq process after loading such a map.

Not great, and that's when you have some kind of execution control based on user-data.

Yesterday xstephx had an issue in #helpdesk where a func_door had some unexpected field value in the nuke map that caused a complaint in the progs with the only result of a message box:

"SV_Error: Program error."

If you're lucky you can use -condebug to get a bit more data, on Windows in a log file, on Linux on stdout via -condebug /dev/stdout, but this way of simply killing the client is way too offensive. Ideally cleanup would be run similar to a /disconnect, and the user could try something else.

This is a very broad and fuzzy issue, but perhaps some offort to deal with the most common ones would be a win.

Another common one mappers experience is loading a map that doesn't contain a info_player_deathmatch, only info_player_start with ./ezquake +map foo results in another exit like the one above.