The existing fbo-blending-formats test is mostly useless for anything but
unorm formats, since it does not test any values outside [0,1] (neither for
src, dst, intermeidate calculations, blend result).
I tried to enhance it but it got too complex, in particular because I really
want to test snorm, not floats (which aren't really validated much neither),
because if you actually use int math for them it's difficult to handle and
llvmpipe had lots of bugs. And it's not even obvious from the GL spec when
clamping actually happens (in particular, the inverse blend factors will be
in range [0,2]). snorm blending is sort of semi-supported in GL, the
presence of EXT_texture_snorm doesn't guarantee it (and nvidia doesn't support
the extension, presumably because they can't or don't want to deal with the
legacy alpha/luminance/intensity formats), and while GL 3.1 introduces the
snorm formats too it isn't guaranteed for rendering neither (for GLES OTOH
there's a EXT_render_snorm extension), so the format handling of the
fbo-blending-formats test isn't really sufficient and not easily extensible.
So, this test will test actual blend behavior with values which will need
clamping, and where the intermediate and final values will be negative (and,
for the inverse blend factors, be even larger than one).
This passes (now) on llvmpipe, and nvidia blob. softpipe is a complete
failure (if there's clamping it will always clamp to [0,1] for starters),
and as a matter of fact, softpipe doesn't get the clamping right even with
unorm neither, since values outside [0,1] won't get clamped in the tile
cache when there's no clamping, hence they'll enter the blend later when
blend is enabled unclamped - but there's no test for this (note this is
only an issue if the fragment color clamp is disabled).

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>