basic collision FIXED

Some integer math for the collision checkers must be examined closer.
==============================================
Adding and subtracting the same offset from the character's dot position
logically results in an odd-number character width. If set too large,
the top and bottom collision checks will collide not with the bottom
block but with the blocks to the right or left of the bottom block.

Possibly convert the collision manager into a physics manager
=========================================
Additionally, having both the character and the physics
manager/collision manager modify velocities and positions greatly
complicates writing collision code. A better model to solve this might
be for the character to store instantaneous properties (position and
velocity) as well as instantaneous intention (user input or AI wants
character to move left). The collision manager/physics manager can then
interpret these publicly accessible intentions into a change in velocity
depending on game mechanics. This modeling does seem like it goes
against typical OOP style of encapsulation. However, this may be more
appropriate as the position-and-velocity-handling might be better
localized in the physics manager rather than spread out among all the
moveable classes.

Still work to do with the collision handler
======================
While the basic logic collision function is in place (which is now more
purely functional rather than relying on a chain of side-effects), I
expect the collision detection to benefit from being able to identify
certain patterns of tile arrangements. (for sensing collision with a
ledge or a passage just fitting the height of the character, which seems
to inevitably glitch unless the corner-detection is refined, which seems
to still necessitate a tile-pattern-parser.)