Fix 382 puzzling getIntersection behavior

Problem:  getIntersection finds a shape at a point in a layer by checking the pixel color  in the hitCanvas at the point.  However when the shape is first drawn into the hitCanvas, pixels on the edge of a shape may be anti aliased.  This leads to the problem in #382 where 2 shapes overlap but overlapping edge pixels are not considered to be in either shape. The edge of the top shape is anti aliased with alpha < 255 into the  bottom shape and the hitCanvas color becomes something in between the two colorKey values

Fix: The fix changes getIntersection to check the 4 pixels next to the target point if the target point has a non zero alpha but the colorKey does not match an existing shape.  One of these pixels should be an 'un anti aliased' color Key and we will find one of the 2 shapes.

Interface change: getIntersection also now returns null if it cannot find a matching colorKey in all cases.  Before this fix getIntersection would return the pixel color if there was no shape found and the hitCanvas color was non-zero. This feature was not used by the code base anywhere and it seems likely to be confusing to users who call getIntersection since they currently must  check obj !== null && obj.shape !== null if they use getIntersection.  (stage _mousemove does not have the obj !== null && obj.shape !== null logic so it should a little better)