Alternative overlay data representation

[orenshatz]

M=5 requires 2GB, for many users this is already unacceptable. M=7 is 5.5GB, that's not even possible on 32bit systems. We need something more efficient than a memory supercube (hard-drive?) or than uint64 (uint32?) or than complete matrix (sparse? but not applicable for complete segmentation. volume run-length compression?). The key point being that at the moment we only actually show 3 viewplanes at a time, which is much less than what we hold in memory, and don't compute anything using invisible information (although this might change with plugins now) - so there's no real need to hold such a huge memory other than rapid slicer retrieval of overlay data during continuous movement. This usecase, while common, is by itself limited my a rather small M. So currently overlay is used mostly statically for local jobs. So higher M's are impossible memory-wise, while lower M's can be served by another solution. The conclusion is that we can already spare the user quite a lot of memory by an alternative implementation, or aim at a higher M that would require - again - an alternative implementation. The current situation is working but a lose-lose one.