(RISCV) fix handling of fixed-point type return values

(RISCV) fix handling of fixed-point type return values

This commit adds support for TYPE_CODE_FIXED_POINT types for
"finish" and "return" commands.

Consider the following Ada code...

   type FP1_Type is delta 0.1 range -1.0 .. +1.0; --  Ordinary
   function Call_FP1 (F : FP1_Type) return FP1_Type is
   begin
      FP1_Arg := F;
      return FP1_Arg;
   end Call_FP1;

... used as follow:

   F1 : FP1_Type := 1.0;
   F1 := Call_FP1 (F1);

"finish" currently behaves as follow:

    | (gdb) finish
    | [...]
    | Value returned is $1 = 0

We expect the returned value to be "1".

Similarly, "return" makes the function return the wrong value:

    | (gdb) return 1.0
    | Make pck.call_fp1 return now? (y or n) y
    | [...]
    | 9          F1 := Call_FP1 (F1);
    | (gdb) next
    | (gdb) print f1
    | $1 = 0.0625

(we expect it to print "1" instead).

This problem comes from the handling of integral return values
when the return value is actually fixed point type. Our type
here is actually a range of a fixed point type, but the same
principles should also apply to pure fixed-point types. For
the record, here is what the debugging info looks like:

 <1><238>: Abbrev Number: 2 (DW_TAG_subrange_type)
    <239>   DW_AT_lower_bound : -16
    <23a>   DW_AT_upper_bound : 16
    <23b>   DW_AT_name        : pck__fp1_type
    <23f>   DW_AT_type        : <0x248>

 <1><248>: Abbrev Number: 4 (DW_TAG_base_type)
    <249>   DW_AT_byte_size   : 1
    <24a>   DW_AT_encoding    : 13      (signed_fixed)
    <24b>   DW_AT_binary_scale: -4
    <24c>   DW_AT_name        : pck__Tfp1_typeB
    <250>   DW_AT_artificial  : 1

... where the scaling factor is 1/16.

Looking at the "finish" command, what happens is that riscv_arg_location
determines that our return value should be returned by parameter using
an integral convention (via builtin type long). And then,
riscv_return_value uses a cast to that builtin type long to
store the value of into a buffer with the right register size.
This doesn't work in our case, because the underlying value
returned by the function is unscaled, which means it is 16,
and thus the cast is like doing:

   arg_val = (FP1_Type) 16

... In other words, it is trying to create an FP1_Type enty whose
value is 16. Applying the scaling factor, that's 256, and because
the size of FP1_Type is 1 byte, we overflow and thus it ends up
being zero.

The same happen with the "return" function, but the other way around.

The fix consists in handling fixed-point types separately from
integral types.