lots of improvements towards making a better game loop/hierarchy

so now Game creates a qquickview, containing our main.qml which is the
main ui and everything. in that main.qml it adds the FboInSGRenderer scene
node, which is the actual game scene. We then grab that pointer, connect
signals, which then go back into Game, which calls Client::paint, going
into Client::render (yeah i know, the whole thing needs cleaned up..).

But hopefully this will work, and I won't have any of that stuff of accidentally
creating 2 clients due to qml/C++ interaction behaviors..
fix build errors associated with last commit

qml no longer needs to know about Client type info, so this fixes that
(by not registering it anymore).

Report qt compiled and runtime version, for better user debugging.
oops, do custom rendering just before binding default fbo instead of after..

(was smashing the qquick fbo)
theoretically reinstate all qml ui elements..but nothing is being drawn

there's no garbage, so that's a start. stop rendering client stuff
until we actually get the ui stuff to render..
ui renders now, it was a z issue (Renderer {} at the bottom instead of

the top of file), and since qml instantiates top-bottom, with z increasing
as it goes further down...the elements were beneath our "scene" (which
was blank).
debug code..
add small assertions, for some impossibilities
woot, back to rendering...was due to qt not disabling depth tests

even though they tell me to leave the GL's state unchanged, they go ahead
and not set theirs back to default...upside currently.
flip camera y, because qt flipped it for us when we moved to the fbo..
quiet debug a bit...add frametime exposed to qml, including signal for it

now onto key event/processing..
minor cleanup
trigger update() in the scene node, for our game scenes blitting to qml

otherwise it's not guaranteed to get rendered each time
style fixes, use qmutexlocker, working towards finally hopefully

getting key presses to work proper
actually, we'll see if client can do without access to the view
add assertions and other checks server-side to prevent

malicious activity..there are other means obviously, less crashy ones..
soon we're going to implement forcibly kicking clients, which will include
not only admin means, but also for automatically kicking clients the server
suspects to have malicious intent
implement client-side assertions for malicious player input..

though obviously it's not really malicious but accidental in this case
(as I am currently experiencing).

but comment it out for now, create a check server-side for such input
activity. I'm surprised I didn't think of it while I was writing it, but
guess I was caught up in "getting it to work".
minor, fix ptr notation, use refs for the ranged for-loop autos
document a lot of server functions, cleanup code rm some dead code,

pass the player pointer instead of just the player name, to the
receiveChatMessage. We'll need it later on, certainly.

begin hashing out a kickClient and kickPlayer function. former is
internal to just the server, for when we need to kick someone before
the server has created a player for said client (this step covers
very early-kick events, like invalid player name, and version mismatch).
refactor the receiveInitialClientData function, move the validation code

from processMessage, and push it into that function instead.

Now we don't have to worry about returning values, handling those in
nasty nested switch statements, and somehow sending the right kick message
if that was decided. It was pretty ugly.
improve version checking on server->client handshake, improve kicking

on validation failure..add the malicious intent flag to disconnect return
value. It's presumed that it'd be only from a malicious method, so other
things that get passed impossibly bad values from the client can be checked
and can kick them if need be. It' snot always malicious though, in the case
of right now, it's just a bug somewhere in the client. But most other
scenarios would be malicious, so prevent it so the server is secured properly.