win32k: NtUserCreateDesktop rewrite

This patch rewrites NtUserCreateDesktop to fix the problem that causes desktop objects to never be freed.
First of all when NtUserCreateDesktop returns the new object has 2 handles and 3 object references. The extra handle is created by CsrInsertObject.
The two handles keep 2 object references and the last refernece is created by ObReferenceObjectByHandle called by NtUserCreateDesktop.
Regardign the extra handle, when we create the new desktop we also create a new thread in csrss, create a duplicate handle in the context of csrss , switch the new thread to the duplicate handle and create there the desktop window. Moreover we don't have any way to destroy the desktop window or the extra handle making it impossible to free any desktop object.
This patch fixes the following issues:

• It rewrites the desktop thread completely to be more like windows. In windows the desktop thread does not belong to any desktop and all desktop windows belong to the desktop thread despite the fact that they belong to different dektops. It also makes reactos use one desktop thread instead of one desktop thread for each desktop. The new logic does not require a duplicate handle or switching to the new desktop. A shortcoming of this change is that as the desktop thread doesn't belong to any desktop it is not safe to do callbacks to user mode cause user32 requires a desktop to be selected.
• It fixes the extra reference by dereferencing the object before returning.
• On top of that the patch fixes another serious problem regarding the message window. Right now we create the message window as a normal window leading to the problem that the window is allocated from the caller's thread deskop and not the new desktop heap. The message window also uses a class that is allocated from the caller thread desktop heap. This could cause problems in the following scenario: a thread crates a desktop A and switches to it, and then it creates another desktop B. The message window of desktop B is allocated in desktop A so in case we ever free desktop A it will also destroy the message window of desktop B. This was not a problem till now cause we never free desktop objects
• In order for NtUserCreateDesktop to allocate the desktop window and the message window from the new desktop we have to map the desktop heap of the new desktop so it was decided to map the desktop heap when a new desktop handle is opened via the desktop object open callout (just like windows does)
• One last tricky part of the creation of the desktop window is the desktop class. It doesn't seem correct to create a desktop window referencing a class that belongs to a different desktop so what this patch does is to call UserRegisterSystemClasses from DesktopThreadMain. As the desktop thread doesn't have a desktop, the class code allocates the classes from the shared heap. So when the desktop window is created we use the classes that are allocated from the shared heap