Marker Visual

Remark: the purpose of this pull request is to prepare a much more interesting pull request where I implemented a simple abstract renderer for markers (which explain why I became maniac on marker and edge sizes)

- corrected GLSL function for markers where some key points are defined relative to fragment size instead of being
defined relative to marker size $v_size: the defaults were visible in the demo/gloo/how_markers.py example on the
clobber marker that was kind of dislocating when becoming too small; they could be seen also as deformation of
bars or cross markers when displayed at very different sizes.
- changed frag rendering so that the size of the marker is the guaranted size in pixel of the face. The edge is
now outside the face and if too small will be mixed with face antialiasing or not displayed if below 1/10th pixel wide
- added marker function rescaling so that the edge have the same width for the same edge_width parameter whatever
the marker (and as far as I checked the edge width is exactly edge_width wide in pixels) and whatever the part
of the marker (before tailed_arrow had a wider edge on the tail than on the arrow)
- added very common markers triangle up and down and star (at least in matplotlib) and changed the total size of the
fragment in vert and frag for the edge to be rendered correctly
- added a RescalingRelativeEdgeMarkerVisual that rescales as the scene is rescaled (see the added example below)
and for which edge is expressed as a fraction of the marker size
This new marker visual can be used with all markers and rescale the whole marker as the minimum of x and y rescaling.
- added a RescalingXYRelativeEdgeMarkerVisual that is similar to the previous one but rescale independently in the x
and y directions. It works only with specific markers called markersxy which are defined for arbitrary x and y sizes
($v_size becomes a vec2). Some of these markers keep a 1:1 aspect ratio (called square markers), using only the min
or the max of the x and y size. The others used both sizes (hbar, vbar, cross, x, rect and ellipse). Note that the
distinction between hbar and vbar does not much sense because of the 2 sizes but is kept for the moment.
Ellipse marker code may seem complicated but the key problem is to correctly rescale the function so that the edge
width is regular around the perimeter of the ellipse. The correct rescaling is given by the gradient of the level set
defining the marker (the marker function in the code) taken at the point on the ellipse for which the normal goes
through the point currently considered in the fragment shader. I could not find a way to keep the code of this
computation siple so I used an approximation: the point on the ellipse is the point corresponding to the hyperbola
constant coordinate in elliptic coordinate system (http://en.wikipedia.org/wiki/Elliptic_coordinate_system).
It's much simpler to compute and the result is nice looking (you can see some defaults by rescaling the ellipse so
that it has a large size and is almost flat).
I'm not really convinced about the need for this. Right now the behavior just seems awkward having the markers suddenly change their appearance, and its inclusion complicates the API and implementation. Anyone else have an opinion on this?