Remove hard coded 640x480, use memmove rather than strncpy for CG_STRNCPY

[jackharrhy]

Two small fixes for issues found while porting to macOS aarch64, but both affect all platforms.

Remove stale vresWidth/vresHeight override in GLimp_SetMode

vresWidth and vresHeight are correctly set to glConfig.vidWidth/glConfig.vidHeight, but then immediately overwritten with hardcoded 640x480 values. This appears to be a debug leftover.

Use memmove for CG_STRNCPY VM syscall

The Q3VM cgame module can pass overlapping src and dst pointers to CG_STRNCPY, since both point into the same VM memory buffer. strncpy does not define behaviour for overlapping buffers - on most platforms this happens to work, but modern hardened libc implementations (e.g. macOS on arm64) detect the overlap at runtime and abort the process.

[leilei-]

Yeah, that must've been from when I attempted to make "tvmode"/virtual resolution (which was pretty pointless as the engine's more CPU bound than rendering, and rendering a virtual 640x480 in GL would require a much more modern video card than where it'd theoretically be practical) and I missed reverting one part. I had a lot of different concepts to improve that I just throw at this repository, see what sticks, and revert off what didn't (by hand). One of the reasons for that old idea was more readable console/notify text, which is now handled in a different commit to scale up the console text recently.

[sago007]

I wonder if a better choice is to use the:

/*
 Copied from code/game/bg_lib.c
 It is here to avoid undifined behavior when source and destination overlap.
 This is used quite a lot in the code.
 */
static char *qstrncpy(char *strDest, const char *strSource, size_t count) {
	char *s;

	s = strDest;
	while (*strSource && count) {
		*s++ = *strSource++;
		count--;
	}
	while (count--) {
		*s++ = 0;
	}
	return strDest;
}

Solution for CG_STRNCPY

I belive memmove technically is undefined in cases like:
memmove(LARGE_BUFFER, "small string", 4096);
As it might read bast the end of the source string.
It is probably not a problem for the VM since there are no holes in the memory but still.

[sago007]

I have an alternative PR #107 that is implements the alternative