WIP: Volume rendering

This PR implements volume rendering. It's basically a port of the technique that I use in Visvis.

* New Volume visual with two rendering styles (iso and mip). 
* Volume example in examples/scene/volume.py Try it, and use the keys to switch cameras etc.
* Refactored cameras a bit in general
* Refactored TurnTableCamera: no more mode and distance. You can just change the fov while getting the same zoom level. Setting fov to 0 means orthographic. Zooming is done by moving camera backward.
* New FlyCamera to fly around your data. 

This is about ready. There are more things to do, but that can be picked up in another PR. (I added todo items for this in volume.py)

I wish to do more with the camera's, but we should probably discuss this first. Will make a new issue for this.

I guess you mean coordinates of the `viewbox.scene` ?  I agree we should have a method for making a particular part of the scene visible, but I will need to be convinced about the best API for that..

There is a very tricky problem here in that the cameras themselves only have ~10 degrees of freedom (x,y,z,pitch,yaw,roll,xfov,yfof,near,far), but we might want to expose many more than 10 parameters for specifying the state of the camera (all the "natural" parameters I listed previously, plus scale_factor, center_loc, view limits, etc). We run into a problem where we want the user to be able to provide any combination of those parameters that fully specify the camera state, while not allowing them to _overspecify_ it. This is a very common user interface problem--for example, SLR cameras have many more controls than degrees of freedom, and they solve this by giving the user different "modes" to work in: auto, AV, TV, M, P, etc., where each mode exposes only a subset of those degrees to the user at a time. 

The set of parameters I picked for the cameras are pretty straightforward / natural, and I think we need to keep those available for users who want to think about physically placing their camera in the scene. At the same time, I like the approach you have taken (the user doesn't care about the camera so long as they can see their data), so we need to figure out how to combine these approaches. It might be best for now to keep each of these as separate camera classes, and we can try to join them together later on if that seems possible.