Fix mksurfdata.F90 format specifiers for GCC 10+ compatibility

[cdevaneprugh]

The I format descriptor without a width is a legacy Fortran extension that fails with strict GCC 10+ compilers. GNU Fortran requires -fdec-format-defaults flag to enable this extension.

Fix:

• For write statements: use I0 (minimum-width format, standard Fortran 95+)
• For read statements: use I6 (read requires positive width)

This matches the coding style used elsewhere in CTSM (e.g., I0 in src/main/abortutils.F90 for output formatting).

Changes:

• Line 271: '(2(a,I))' -> '(2(a,I0))'
• Line 295: '(i)' -> '(I6)'
• Line 328: '(a, I, a, I)' -> '(a, I0, a, I0)'

Tested on: HiPerGator (UF HPC) with GCC 14.2.0

Reference: https://gcc.gnu.org/onlinedocs/gfortran/Default-widths-for-F_002fG_002fI-format-descriptors.html

Description of changes

See above.

Specific notes

Portability fix for GCC 10+ compilers which enforce stricter Fortran standards.

Contributors other than yourself, if any:

CTSM Issues Fixed (include github issue #):

Are answers expected to change (and if so in what way)?
No - diagnostic output formatting only.

Any User Interface Changes (namelist or namelist defaults changes)?
No

Does this create a need to change or add documentation? Did you do so?
No

Testing performed, if any:
Built mksurfdata_esmf successfully on HiPerGator with GCC 14.2.0.

[ekluzek]

We'll want this to go to b4b-dev like #3700, but we'll undoubtably have the same problem rebasing this one as well. So same solutions apply.

[ekluzek]

Yep, this is a fortran standard issue as well as something to make the formatting intended clearer. So good change to bring in.

It looks like the reason we don't see this in our testing is that we are currently only testing on Derecho with the intel compiler. We have gcc/12 on both Derecho and Izumi that we use for testing the model. But since we don't try testing mksurfdata-esmf with GNU or on other machines -- we don't see this. I was concerned that this might have meant we have problems like this in the model as well, but since we test with gcc 12+ we hopefully don't.

Thanks for this one as well @cdevaneprugh