Make routing table generation consistent

### Are there any linked Issues or Pull Requests?

_No response_

### Brief description

Currently, the routine that generates of halo routing tables takes the type of the field data (real or integer) as an argument, but its use in the generation has been removed. It either needs to be readded to the generation or removed completely from the routine.

### Further details of the issue.

It has been noted that the routine `get_fortran_type()` exists in `source/utilities/halo_comms_mod.F90`, but isn't actually called from anywhere.

Investigation into the usage of this routine reveals it was added when support for halo exchanges on all types and kinds of fields was added in SRS ticket #1975. Then, in order to save some time when generating "fat" halo routing tables in SRS ticket #4055, the code was changed so the same routing table was used for all data of the same size, irrespective of the type, so for example, a 32-bit integer field uses the same routing table as a 32-bit real field. Obviously, there was now no need to know the type, so the call was removed, but `get_fortran_type()` wasn't removed and the type to check against is still passed as an argument to `get_halo_routing_from_list()`.

The call to Yaxt that generates the routing table takes different arguments for real and integer fields, so the Yaxt documentation never explicitly states that all 32-bit fields (integer or real) will use the same redistribution table. It just happens to treat the data as blocks of 32-bit data, so produces identical routing tables. There is no guarantee that Yaxt will continue to do this - but then, on the other hand, it also seems unlikely that it would change.

Calculating separate, identical routing tables for integers and reals would slow down initialisation and seems like a complete waste of time, but it would probably be the most "correct" thing to do.

We have to decide if were happy to take the risk of using an undocumented feature in Yaxt. If not, we should re-introduce the call to `get_fortran_type()`. If we are happy to use that feature, the type should be properly removed from all routing table generation calls.