Fix view matrix programmable

fixes #3151.

When drawing directly after ```mCam.begin()``` the ```ModelViewProjection``` matrix would not have been properly set up (see also: renders & test case in #3151). The same issue might also have led to a virtual one-frame lag in camera updates in some situations.

This because a camera would just update the ```View``` matrix, but this update would not automatically cause the dependent matrices further up it's hierarchy to re-calculate. 

### This PR addresses this issue by:

* DRYing matrix stack code so as to have unified execution paths
* Uploading matrices to the shader in one central location
* Making sure view matrices can only be updated whilst matrixMode == ```OF_MATRIX_MODELVIEW```
* Making sure matrices dependent on ViewMatrix get updated whenever View changes.
i agree it would be nice to get rid of matrixMode renderer state and manipulate the matrix hierarchy directly. But that would probably mean a quite some changes to the matrix stack and how we're handling matrices, building something like a minimal ```orientation * projection * view * model``` –  stack graph.

i've put the check in here because the alternative would have been to quietly change the matrix state to OF_MATRIX_MODELVIEW as a side-effect of changing the view matrix, and i wanted to keep things DRY and in line with our current stateful setup.

Also, i'm not sure if the View methods are exactly doing what they say, since they effectively reset the ModelMatrix, which you might want to leave untouched in some cases.

To make things future-proof, I think it could be good to decouple & move the shader matrix upload methods to the ofShader object, so that ofShader can decide for itself how to push these uniforms to the GPU, whether as in now with attributes or by updating a sub-region of an UBO in a bindless future...