Add basic orbital camera implementation

[maaxxaam]

The aim of this PR is to resolve #13 by adding a mouse/gamepad controlled third person camera that orbits around player character. Camera's features include:

• Orbiting around and following player with smoothing
• An ability to switch shoulders
• Aiming a "weapon" with changing FOV
• An ability to focus camera at a specific point (that should be useful for implementing scripts later on)
• Responding to static scenery by shortening orbit radius so character stays in camera's view

[maaxxaam]

That's weird: player character seems to start travelling at incredible (around 20 orders of magnitude higher than normal) speeds from the start of the game which prevents me from testing the camera. I did test the code before the PR; however, I also did a rebase onto master right before pushing since my dev branch was 13 commits behind. Could the recent AI additions cause the character controller to break?

[Nostritius]

Hi I tested your pr and noticed, that I made an error in the character controller leading to strange walues. It should be fixed in the last commit

[maaxxaam]

Thank you for the fix! I've rebased the branch off the latest commit, testing should be easier now.

[maaxxaam]

Hmm... That's odd. According to the failed build logs for commit 89fc1b2, it looks as if awe cmake target for Mac has arm64 architecture set while all of the previous targets were built for x86_64, leading to >600 lines of reference errors. I'm not sure that's supposed to happen here - after all, recent mac universal binary commits that could lead to such behavior are not included in this branch yet. :thinking: Upd.: checked out build logs for the latest master commit - apparently, it suffers from the same issue.

[maaxxaam]

Alright, I hope I didn't go too much into commenting OrbitalCamera's behavior, but it should explain a lot more choices that were made to make the camera feel better and closer to original game's one.

Regarding the character issue: I actually have a code snippet to do that - it was intentionally left out to make this PR focused on camera only. After what happened to the event handling PR that grew double the size because I kept adding more related stuff to it, I hope that keeping changeset constrained would be the better experience for both of us (if you think otherwise - feel free to say so, I'll add that in).

Moreover, it is not completely obvious where the central place of control should be since we have at least two different ways to look at and navigate the world - through character movement and orbital camera and through free camera. I've been testing an option to make a CameraDirector class that would control storing and switching between cameras as a possible solution, but that also includes changes to event handling (namely, adding an option to remove a callback from action), which should probably be an its own PR really.