Fix movement at landscape boundary by implemeting elastic scattering

@mlange I implemented the proper indirect shortest path computation for the torodial circle in the second commit but the result is rather unintuitive due to the metric discontinuity at the landscape boundary, i.e. to hit something on the other side while going in a straight line all at way, the entities have to move "sideways" onto the boundary to be aimed into the correct direction on the other side of the circle.

I think the second commit is topologically sound (I gained 12 pages of trigonometrics and lost one pencil while figuring it out.), it really will be hard to explain and to generate the expected shortest path, the entities would have to change direction at the boundary which sort of defeats the purpose of avoid boundary effects.

Hence I decided to go for elastic scattering at the boundary for now which is simple to implement, looks believable and should introduce minimal distortions to the constant-velocity random movements. A square torus would have been another alternative, but it would be a more intrusive changes and also imply computing 7 candidates for straight-line shortest path.