Basic structure of pyFMS package

[fmalatino]

Description This PR sets the basic layout of the pyFMS package. The pyFMS package allows for interoperability between some of the modules contained within the Flexible Modeling System and NDSL. Code contained within this PR is purely structural and cannot be used as of yet for true interoperability.

Use of the pyFMS package is as follows:

A shared object library, compiled from the source Fortran code containing the desired c-binded FMS modules must be made local to the installation of NDSL. The desired location for the file is within NDSL/external/FMS

Each c-binded FMS module will have an analogous python module contained within, which will contain functions which obfuscate the Fortran functionality, allowing for them to be used in a "pythonic" way. This can be seen in the subdirectories of pyFMS.

The pyFMS module makes use of the __init__.py module method for importing of the FMS functionality. For example to call the fms_func function the user would use the following format:

import ctypes as ct
import pyFMS

lib_fms = ct.cdll.LoadLibrary(lib_file)

pyFMS.fms_func(lib_fms, args)

How Has This Been Tested? Tested via lint and currently implemented translate tests OS: RHEL 8.9 Ootpa Built conda environment using workflow in github action configurations

Checklist:

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

[fmalatino]

@xyuan 1) Yes, the files with import ctypes, such as pyFMS_block_control.py for example, will contain the python wrapper functions.

2) I am impartial to where the tests will exist. I will gladly implement whatever the consensus decides.