Fixes msvc release. Adds build artifacts so non release exes can be accessed. Reworks installer

[fundies]

No description provided.

[JoshDreamland]

Looks like a PITA; thanks for dealing with this.

[RobertBColton]

Inside the server plugin constructor, you will see timer->start(); which I think may be partially part of the problem. We should be passing 1 to this function which means a 1ms delay between triggering of the async server plugin event processing. Without that parameter, the default is 0 which means to trigger the timer constantly which results in 100% utilization of a single CPU core, or 100% of the CPU in a single core processor.
https://wiki.qt.io/Threads_Events_QObjects#When_shouldn.27t_I_use_threads.3F

I recently discovered this while working on some of the new broadphase stuff with the update loop I had written there. Utilizing a full core is fine for a video game, but not really for an IDE, especially async event handling. For example, Qt Creator's own clang model plugin doesn't use 100% of a single core while idling, and thus neither should RGM. For that reason, I would like to find some other way to allow the server plugin to receive a regular interrupt from the main Qt event processing. QMetaObject may just be such a solution.
https://wiki.qt.io/Threads_Events_QObjects#Jobs_splittable_in_chunks

[RobertBColton]

Read here for further explanation:
https://stackoverflow.com/a/24153731

Basically, I think you can in fact use QTimer with 0ms delay, but you need to make it single shot and then just have it invoke itself again to avoid hogging the CPU.

[RobertBColton]

Ok, after further discussion with Rusky I finally figured out what we need to do. The last resort is to sleep or set a delay on the QTimer, because QMetaObject::invokeMethod changes absolutely nothing as QTimer ultimately uses that underneath anyways.

We have several ways of solving this problem. We could for example look and see if GRPC has some sort of underlying interrupt outside of Qt's event loop and use that to schedule an update using QMetaObject::invokeMethod to handle GRPC events. We could also check to see what native events may be occurring at the same time GRPC events are being created. This makes sense that RGM can only respond to GRPC events when the OS has actually fired the underlying events which lead to their creation (e.g, such as the connection buffer being filled).

[RobertBColton]

Alright, so I did some more digging while actually trying out the thread solution from Rusky and bumped into some great news. The GRPC devs basically admit that is an issue with integrating GRPC into foreign event loops, and they are currently working on a solution, but for now what Rusky recommended with a thread is the accepted workaround.
grpc/grpc#14796
grpc/grpc#20194

The underlying issue is actually in GRPC Core which GRPC++ is just sitting on top of.
grpc/grpc#14565