Fix camera to follow player eyes when player is attached

[sfence]

• Goal of the PR
  Make the player camera follow the player's eyes independently on attached offset and rotation and parent object rotation.
• How does the PR work?
  Change the camera position setting.
• Does it resolve any reported issue?
  This probably resolves bug issue Strange camera behaviour if attached to object and shifted the eyes. #10101 and more.
• Does this relate to a goal in the roadmap?
  I have no idea.

To do

This PR is a Ready to Review

How to test

Run devtest game, add testentities:attach entity to the scene, and right-click to attach yourself to it.
Control keys are up, down, left, right, jump, sneak, and aux1. aux1 changes the mode of control.
To check get_look_dir, take the testlookdir:fire item and use the dig/place buttons to the fire entity in the direction of look_dir get from get_look_dir or calculated from get_look_vertical and get_look_horizontal.

You can detach this branch HEAD to one commit before commit "Fix camera position and rotation." to see how it works without a camera fix.

See before :
https://streamable.com/ih3lb5

And after:
https://streamable.com/tvdztt

[sfence]

@APercy This can be interesting for you and my rocket mod.

[appgurueu]

Such a fix is much needed and useful, but I have some concerns about breakages, esp. since there are no changes to the Lua API.

Before this PR, the camera did not have roll, and even though the player visuals could be rotated, the eye position could always be found by adding eye height to the player pos. This PR changes that, and gives mods no convenient way to detect this or to find the new eye pos; mods would have to query attachments and compose transformations themselves.
(I'm unfortunately not sure whether we can expose a good server-side API, since the player might be attached to an animated model, which the server doesn't understand. But at least for the common special case where no bones are involved, we could make a decent effort.)

Calculating look dir from pitch and yaw will also be broken (there is no way around this when adding roll, but again, modders need to be able to deal with it.) Also, won't get_look_dir be broken (as in: was absolute, now is relative to attachment) too?

What it boils down to: Wouldn't this break firing a bow from the test entity, both in terms of finding the eye position and the direction the arrow should go? And if so, how can we best update the API such that modders can deal with this?

There also is a compromise that doesn't add roll (yet), where you would only apply yaw and attachment offsets. This would already be good enough for e.g. car mods.

[sfence]

Works pretty well now until attachment rotation uses the roll (axis Z in vector) part of the rotation.
get_look_vertical and get_look_horizontal still unchanged.

[sfence]

So, now the matrixes are used to calculate positions and rotation in the way, how it Is done on the client side.
World relative pitch and yaw are calculated from the camera direction vector on the client side and sent to the server.
With this, pitch and yaw should work naturally on old and new clients on the same server.
Position returned by Lua minetest.get_pos respect attachments and rotations.

[sfence]

@appgurueu Is it a good idea to detect the player client protocol version in minetest.get_eye_pos and minetest.get_pos and return values in the old style for players playing on old clients?