ENH: refactored coordinates system for stimuli

Substantial rewrite of coordinate system for rendering visual stimuli.

*Previously:* pos and ori were used (by glTranslate and glRotate) to calculate the stimulus vertices by OpenGL and scaled (glScalef) to the screen using an affine transform (so 1 deg of visual angle had the same size in pixels at all points on the screen).

*Now:* stimuli calculate the x,y positions of their own vertices using that same information. The window is left in pixels as its native scale. This means
  - stimuli always know their vertex locations in a single coordinate framework (stored as stim.verticesPix) making contains() and overlaps() methods simpler
  - vertices can now be corrected more generally for non-affine transforms to correct for the fact that parts of the screen further from the centre have fewer degrees per pixel.

Side effects:

1. By being done in the CPU rather than graphics card this will be fractionally slower when those values change but fewer commands are needed at draw time. these will still be pretty fast though - vectorised matrix maths formulae are used to calculate the vertex locations in pixels
2. stimuli (notably subclasses of stimulus) that were directly accessing or overloading any of the following (private) methods and attributes will be broken:
  - `_posRendered`, `_sizeRendered`....
New attributes for most nearly all stimuli:
  - `verticesPix` the array of XY vals in pixel coords, accounting for pos, size, ori and units
  - `_verticesBase` the base vertices that will be combined with the size and pos etc. to create the final verticesPix
  - `_updateVertices` the method to calculate `verticesPix`
  - `_needVertexUpdate` a flag to indicate the vertices should be recalculated before next access (this is done automatically on-access)