Bug 566: Implement handling of unisolid slopes.

Bug 566: Implement handling of unisolid slopes.

The current code handling unisolid tiles only works correctly with normal,
quadratic tiles. The attached patch implements correct handling of unisolid
slopes.

Whether or not an unisolid tile is solid depends on two factors: The movement
of the player and the position of the player.

Checking the movement of the player is simple with quadratic tiles: If the
y-component is positive, the player is moving "down" and the tile should be
solid. Otherwise, the tile is non-solid. With slopes the check is more complex:
A player may move "up" and still move "against" a slope tile which should then
be solid. The patch introduces a new function "check_movement_unisolid" which
compares the tangent / gradient of the slope and the movement and decides based
on that.

Again, checking the position of the player is easy with quadratic tiles. If
(tile.top > player.bottom), the player is above the tile. Otherwise, the player
is below of in the tile (for example when the player jumped up through the tile
but not enough to reach the surface). With slopes, the check is more
complicated because the player may be already within the tile but still above
the surface. Especially with DEFORM1 the player may be more than 16 pixels into
the tile without reaching the surface. The new "check_position_unisolid"
function introduced by the patch handles these cases correctly.

Last but not least: With north-west and north-east slopes there are unisolid
tiles which can be passed from top to bottom but which are solid when moving
from the bottom up. The functions introduced by the patch handle these slopes
correctly, too.

Resolves: #566.

git-svn-id: http://supertux.lethargik.org/svn/supertux/trunk/supertux@6301 837edb03-e0f3-0310-88ca-d4d4e8b29345