Add support to gmm to correctly read 24bit heighfields

(ThomasEgi) code is already in the source, but commented out. might need slight change , the _val was removed.
on grayscale images green and red will return 0 so blue needs to be the one with the big multiplier.also divider and multipliers needed fixing.(yes it really is 255 for sure. i tested it in python on real images)
return double(_heightfield.get_red(int(x),int(y))
              + _heightfield.get_green(int(x),int(y)) * 255
              + _heightfield.get_blue(int(x),int(y)) *65025 ) / 65281.0;

(pro-rsoft) Isn't there a better way than the huge divide (might run into rouding errors), by doing something like divide by 255 instead of multiply? Also, are you *sure* it's 255 and not 256? That would mean (255, 0, 0) is the same as (0, 1, 0) ?

(ThomasEgi) .. whaaa. just noticed my so-called-perfect-test-image gradient had an one-pixel error at that very posistion.
so it in deed is 256. for really sure this time. so it would be 256, 256*256 . and divide through 65793.0
alternatively one could also divide the red channel through 256, leave the green the way it is, and do
*256 on the blue. divider would be 257.00390625 . red channel will incement the heigth by 0.000015259 per pixel brightness.
i dunno whats better. play with 65k values or values as low as 0.000015. both formular results in exactly the same value on python. precision i observed there was totaly ok. after all those are only 24bit accuracy. most cpu can handle 32bit so from my ignorant point of view it should be somehow ok.

(pro-rsoft) I looked how another lib does it and made it like this:
height = red, green / 256 , blue / 65536