Fix undefined behavior in the Fortran, Go and Pascal number parsers

Fix undefined behavior in the Fortran, Go and Pascal number parsers

This commit ports these two fixes to the C parser:

  commit ebf13736b42af47c9907b5157c8e80c78dbe00e1
  CommitDate: Thu Sep 4 21:46:28 2014 +0100

      parse_number("0") reads uninitialized memory

  commit 20562150d8a894bc91657c843ee88c508188e32e
  CommitDate: Wed Oct 3 15:19:06 2018 -0600

      Avoid undefined behavior in parse_number

... to the Fortran, Go, and Fortran number parsers, fixing the same
problems there.

Also add a new testcase that exercises printing 0xffffffffffffffff
(max 64-bit) in all languages, which crashes a GDB built with UBsan
without the fix.

I moved get_set_option_choices out of all-architectures.exp.tcl to
common code to be able to extract all the supported languages.  I did
a tweak to it to generalize it a bit -- you now have to pass down the
"set" part of the command as well.  This is so that the proc can be
used with "maintenance set" commands as well in future.

Change-Id: I8e8f2fdc1e8407f63d923c26fd55d98148b9e16a