rename horiz_interp subroutines

[mlee03]

Description

In this PR,

1. New public generic interfaces were created as alternatives to currently existing all the horiz_interp_*_new public interfaces. These new interface names better reflect the functionalities of the subroutines. The original interfaces have not been removed to avoid making changes to all codes that use FMS.
2. The private subroutine names were changed to better reflect their functionalities.

The new names are:

1. horiz_interp_conserve_version1 --> horiz_interp_conserve_1dx1d
2. horiz_interp_conserve_version2 --> horiz_interp_conserve_2d
3. horiz_interp_conserve_new --> horiz_interp_conserve_get_weights
4. horiz_interp_bilinear_new --> horiz_interp_bilinear_get_weights
5. horiz_interp_bicubic_new --> horiz_interp_bicubic_get_weights
6. horiz_interp_spherical_new --> horiz_interp_get_pre_weights
7. horiz_interp_new --> horiz_interp_get_weights
8. horiz_interp_base_* --> horiz_interp_from_weights_*
9. horiz_interp_solo_* --> horiz_interp_*

In addition,

1. the subroutines horiz_interp_solo_old_r4/8 were removed.
2. Data_override, amip_interp, and interpolator were updated to reflect the name changes.
3. horiz_interp tests were changed to test both the legacy and new names

This PR is relevant for the undergoing efforts to remove interpolation-related code redundancy across MSD-managed repositories by relocating all re-gridding algorithms to FMS. Renaming the subroutines will facilitate FMSgridtools development.

Fixes #1746

How Has This Been Tested?
Make check passes on the amdbox with GCC

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules
• New check tests, if applicable, are included
• make distcheck passes

[bensonr]

@mlee03 - The description states there will be changes needed to component models. The last discussion on this topic was to allow local reference changes, but keep the module procedure interfaces unchanged. Is this still the plan?

[mlee03]

@bensonr
I'll be honest, I'm not recollecting that discussion...

It seems like the GFDL models call horiz_interp_new, so this PR would require changing horiz_interp_new to horiz_interp_get_weights in the model code.

The horiz_interp_conserve/bilinear/bicubic/spherical_new are public but are not called in the models.

If there's opposition, horiz_interp_new could remain as is and only rename horiz_interp_conserve/bilinear/bicubic/spherical_new to *get_weights...

[mlee03]

But..

In the model, there's a lot of this sequential call:

call horiz_interp_new
call horiz_interp

It would be much more clearer if this changed to

call horiz_interp_get_weights
call horiz_interp

[mlee03]

This is a random change that corrects the comment for the test

[mlee03]

@bensonr @thomas-robinson, procedure pointers pointing to generic interfaces is not allowed. As a workaround, new generic interfaces were created where, for example, horiz_interp_new and horiz_interp_get_weights are identical and only differ in name.

[bensonr]

@mlee03 - thanks for testing procedure pointers and finding out the limitations. The documentation explaining the duplication is spot on.

[mlee03]

@rem1776, fixed what you pointed out

[mlee03]

On second thought, this PR is not needed and will probably introduce unforeseen issues. The subroutine names work as they are. Closing this.