Improve command arguments of SOM layout

[BerndDoser]

The SOM layout will be defined with --layout, --som-width, --som-height, and --som-depth. To be prepared for future more complex layouts, e.g. growing self-organizing maps, the definition of the sizes should be part of the layout option, so that the new definition would be:

--layout cartesian 5 5 for a 2-dimensional quadratic map
--layout cartesian 10 10 10 for a 3-dimensional quadratic map
--layout hexagonal 11 11 for a hexagonal map

[tjgalvin]

Does it make much sense to have the internals in pink always treat a SOM as a three-dimensional one? A 2D SOM is just a special case of a 3D SOM. Or is the idea to allow an arbitrary number of dimensions? Dare I say four dimensions?

For my own code that I use to interact with the binary files I always convert coordinates to a 3D type scheme to help minimize the number of cases to write.

[BerndDoser]

The layout SOM and data should be full generic. For the cartesian layout n should be an arbitrary number. Future ideas are also nested layouts or tree structures for a SOM. In the main code the generic design is implemented. Only in some heritage code, like InputData, old C structures will be used.