SQUASH: pack_float*() don't allow float to non-normalized integer conversion

Squash into the patch that adds format_pack.py

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
TEST: fix bin/ext_texture_integer-texture_integer_glsl130 -auto -fbo

-----------------------------------------------------------------
DOUBLE CHECK WITH IAGO IF THIS IS THE PROPER SOLUTION
-----------------------------------------------------------------
    If was failing in the following case:

    glTexImage2D(GL_TEXTURE_2D, 0, info->IntFormat, TexWidth, TexHeight, 0, info->BaseFormat, type, buf);

    info->IntFormat == GL_RGB10_A2UI --> DST  ---> MESA_FORMAT_R10G10B10A2_UINT
    info->BaseFormat == GL_BGRA_INTEGER -> SRC     --------> MESA_FORMAT_B10G10R10A2_UINT
    type == GL_UNSIGNED_INT_2_10_10_10_REV -> SRC  -------/

    Inside of texstore_rgba(), it calls _mesa_format_convert() with
     srcFormat MESA_FORMAT_B10G10R10A2_UINT == 114
     dstFormat MESA_FORMAT_R10G10B10A2_UINT == 115

    Inside _mesa_format_convert(), it results that they are not array formats,
    rebase_swizzle is false, and all the fast paths are not compatible.

    So, at the end, we need to convert to float, uint32.

    Then discovered that _mesa_get_format_datatype(src_format) and
    _mesa_get_format_datatype(dst_format) both return GL_UNSIGNED_INT, but
    as a result of the switches, src_integer == dst_integer == false which is not
    correct as both formats are non-normalized unsigned integers.

    The source conversion goes without failing any assert... but the problem
    was in destination:

    It ends up calling _mesa_pack_float_rgba_row() (line 517 of format_utils.c)
    because it is not an array format. Then, we are converting a float format to
    a non-normalized unsigned int.

    As we have removed that support in previous commit, the "Invalid Format!"
    assert is hit in _mesa_pack_float_rgba_row().

    ----------------------------------------------------------------
    WHAT HAPPENED BEFORE REMOVING float to non-normalized integer conversion support
    in autogenerated format pack functions.

    If we don't remove float to non-normalized integer conversion support but apply
    clamping as Jason asked, this test fails without crashing.

    It fails because, as destination format is non-normalized
    integer, the code basically does a cast to unsigned int (after checking
    the float value against the max and min values of the integer).

    Unfortunately, the float values are 0.x so they become 0 after
    conversion. Hence, the test fails.

    Going back in time, i.e before applying the clamping in float to
    non-normalized integer conversion, it was working.

    This was happening because it was wrongly doing a float-to-NORMALIZED-integer
    conversion, which was fixing the wrong aforementioned source format conversion:
    it made two wrongs into a right.