ofImage seems redundant (long term)

While writing issue #1690, I started questioning why ofImage exists as a class that can be instantiated.

In my mind it seems that ofImage is really a container of ofTexture and ofPixels with load/save routines.

• With ofLoadImage() we can already directly load to ofPixels and ofTexture.
• It almost never makes sense to use a bunch of ofImages over a combination of ofTexture/ofPixels other than to (maybe) save a few lines of code.

ofImage seems to me like a shortcut for very simple tasks, like loading and displaying one image really easily. Beyond that, for more advanced tasks, I think it can get a bit confusing to use, and actually less useful once you have to start using setUseTexture(false), for example.

I'm sure there are a lot of valuable use cases for ofImage that make it convenient for beginners to learn oF, but I also think it makes things more confusing later down the line to have to learn about the difference between main memory and GFX memory. In an OpenGL focused graphics library, this concept is very important.

Start with issue #1690 and compare the stated roles of ofImage, ofLoadImage(), ofTexture, ofPixels, and setUseTexture(false). Done requires a maintainer decision on whether the long-term API should change; this issue names no files or tests.