`win32trace` global namespace handling may be simplified

[Avasam]

Taking this as a technical debt note:

win32trace has special handling for pre-win2k/XP when it comes to global namespace.

It seems the code can likely be simplified now that the minimal supported Windows version is Windows 7 (Windows 8 for Python 3.9+).

pywin32/win32/src/win32trace.cpp

Lines 43 to 75 in e319b77

	// Global\\ etc goodness:
	// On NT4/9x, 'Global\\' is not understood and will fail.
	// On 2k/XP, anyone can create 'global' objects.
	// On Vista, you need elevated perms to create global objects - however, once
	// it has been created and permissions adjusted, a user with normal
	// permissions can open these global objects.
	// As a service generally will be able to create global objects, we want a
	// non-elevated Python to be capable of automatically using the global space
	// if it exists, but coping when it can't create such an object (a local
	// one is probably fine in such cases).
	// [Why bother?: without the Global namespace, a 'win32traceutil' running in
	// a 'Remote Desktop' session would not be able to see output from a
	// service - they have different local namespaces]
	// This means:
	// * We first check to see if the mutex exists in the local namespace. If it
	// does, it we use that namespace for all objects.
	// * We then try and create a mutex in the global namespace - if this works, we also
	// use the global namespace.
	// * We then create the mutex in our local namespace and use that for everything.
	// (Ack - the above is only true for CreateFileMapping - creating mutexes etc
	// works fine)
	// This behavior is controlled by a global variable set at mutex creation time.
	BOOL use_global_namespace = FALSE;
	static const TCHAR *FixupObjectName(const TCHAR *global_name)
	{
	if (!use_global_namespace)
	return _tcschr(global_name, '\\') + 1;
	// global prefix is ok.
	return global_name;
	}

pywin32/win32/src/win32trace.cpp

Lines 590 to 613 in e319b77

	// See comments re global namespace above - the problem child is
	// CreateFileMapping - so we temporarily use that just to work out what
	// namespace to use for our objects.
	// is the "Global\" namespace even possible? It was first made possible in
	// win2k, so yes, it is!
	// see comments at top of file - if it exists locally, stick with
	// local - use_global_namespace is still FALSE now, so that is the
	// name we get.
	HANDLE h = CreateFileMapping((HANDLE)-1, &sa, PAGE_READWRITE, 0, BUFFER_SIZE, FixupObjectName(MAP_OBJECT_NAME));
	if (GetLastError() != ERROR_ALREADY_EXISTS) {
	// no local one exists - see if we can create it globally - if
	// we can, we go global, else we stick with local.
	use_global_namespace = TRUE;
	HANDLE h2 =
	CreateFileMapping((HANDLE)-1, &sa, PAGE_READWRITE, 0, BUFFER_SIZE, FixupObjectName(MAP_OBJECT_NAME));
	use_global_namespace = h2 != NULL;
	if (h2)
	CloseHandle(h2);
	}
	if (h)
	CloseHandle(h);
	// use_global_namespace is now set and will not change - all objects
	// we use are in the same namespace.

If the described Windows Vista (and above?) permission issue causes this special handling to still be valid, the comments can at least be updated.