removed shadername, fixed renderer package naming

[sg3des]

1. removed Shadername from creating objects and Renderable
2. fixed examples
3. fixed naming for renderer package and its sub packages
4. added axis - this is attempt to escape XZ lock, plz look at this: lines 363-367 and fully relize it only for CreateWireframeCircle. example:

genCircleSegData(xmin, ymin, zmin, bottomRadius, circleSegments, X|Z) - XZ plane 
genCircleSegData(xmin, ymin, zmin, bottomRadius, circleSegments, X|Y) - XY plane 
genCircleSegData(xmin, ymin, zmin, bottomRadius, circleSegments, Z|Y) - ZY plane 
et.c.

I think it is convenient

[tbogdala]

I like it and appreciate the effort to make the patch. I'm gonna ask for one more change to the axis idea (which i think is great!):

Using iota like that means X=1, Y=2 and Z=3 so using Z in a logical OR won't work right since it will test positive for X and Y.

I think you can fix this by using 1 << iota which will do the bit shift each time. If you patch that in, I'll merge in the pull request.

[sg3des]

you are not right, iota define safe values: X=1, Y=2, Z=4! next value = 8, et.c.
do not hurry merge request, if this method suits, let me change other functions

[tbogdala]

This was what I was thinking of: https://golang.org/ref/spec#Iota.
I put a small test into the playground here: https://play.golang.org/p/xZBmtkk8is

I do like the idea setting planes via a bitmask like that. If you want to go ahead and do that for the rest of the primitives where it makes sense, that'd be great.

[sg3des]

https://play.golang.org/p/IHFZIKhW_L

[tbogdala]

Yes.

Did you have it that way the whole time and I completely misread that line? If so, that was just a proofreading error on my part and carry on. (whoops!)

I thought you were not bitshifting the iota result.