WIP -- Feature of texture mipmap -- Don't merge yet!

Adding mipmaps to ofTexture turned out a little more involved than i initially assumed, mostly because there are many things to consider when tinkering with ofTexture =)

I've chunked my edits into task-based clusters to make review a little bit easier, and elaborate a little more on topic in each individual commit.

I've got a couple of suggestions and questions i'd like to address before pushing forward: 

### Should we separate texture compression and texture mipmapping, since they are not related? 
→ I'd favour separation, and i'd like to remove the tex-compression specific code from loadData() 
see:
https://github.com/tgfrerer/openFrameworks/blob/c9e13b053bb9a500667fbb2af3e80bc7142f3f1f/libs/openFrameworks/gl/ofTexture.cpp#L543

### Should we drop the glu based legacy mipmap generation?
→ I'd support removing this part, since it's the last hold-out for glu in our codebase, and XCode greets it with nasty deprecation messages, saying it won't be tolerating it for much longer.
see: https://github.com/tgfrerer/openFrameworks/blob/c9e13b053bb9a500667fbb2af3e80bc7142f3f1f/libs/openFrameworks/gl/ofTexture.cpp#L586


### Mipmaps need to be generated whenever texture data is loaded: Should we follow the example of ofEnableArbTex() and enable mipmap generation as an API state through e.g. ofEnableTextureGenerateMipmaps()? 
→ I'm not sure about this, and would feel better not to introduce any more openFrameworks specific state, and add mipmap auto-generation as a member attribute.