Add getRGBVector3i() to every point type with RGB

[taketwo]

Currently only some of the point types with RGB have methods to access their RGB data as an Eigen vector.

This commit moves definitions of getRGBVector3i() and getRGBVector4i() inside PCL_ADD_RGB macro so that every point type with RGB field gets these functions.

It is not a part of this pull request, but I would propose to rename getRGBVector4i() into getRGBAVector4i() to make it clear that it produces a vector where last value is alpha channel. What do you think?

[taketwo]

By the way, these functions create a copy of the data (unlike e.g. getVector3fMap() for xyz data, which provides a map). I am not sure what was the motivation to have only copying vector access. Should we change them to getRGBVector3iMap()?

[jspricke]

Hi Sergey, great finding, I would propose a have the RGBA version in the macro (and leaving the RGB version in place, so we are backward compatible) and using the Map style as well, I don't see a reason to return a copy there.

[taketwo]

To summarize:

• added getRGBAVector4i() as a synonim for the old getRGBVector4i();
• added getBGRVector3cMap() and getBGRAVector4cMap() to access as a map. There is no standard typedef in Eigen for vectors of uint8_t, so I adopted Vector3c where 'c' is for 'char'. Additionally, function names reflect the fact, that you get RGB components in reversed order;
• massaged other macros to give everything a consistent look;
• added unit test for all combinations of point types and Eigen vector accessors.