Update Schmidt Transform for higher resolution

[mathomp4]

Closes #228

This PR contains code from @wmputman updating the Schmidt Transform code.

From my tests it does not affect anything if you are not running a stretched grid, but if you are it seems to change the answer (as expected as I'm guessing coordinates are different). I'm guessing your own tests would show this too.

NOTE 1: Let me know if you'd like me to change any names. f_p comes from our code and it's not too "ESMF-y".

NOTE 2: I'm also using:

integer, parameter:: f_p = maxval(selected_real_kind(15),selected_real_kind(20))

because compilers like NVHPC do not support 128-bit reals (aka quad precision). @tclune was kind enough to tell me I could do this rather than creating a new #ifdef and needing to fiddle with the build system (since by Standard, -1 is returned for non-supported kinds). But this does sort of mean things would be "different" on a per-compiler basis without much user notification.

[oehmke]

We (esmf core team) talked about this and decided that we should allow the user to turn this on. Otherwise, the code will give different results depending on whether quad. precision is available in the compiler. The idea is to add another option under coordCalcFlag to allow the user to request this. If it's not available, then an error will be returned. I also brought this up with NASA and they were fine with it.

[oehmke]

I talked to NASA team and they said to not worry about putting this in. They have changed how they do things and are now getting coordinates directly from the FV3 model and so don't need to worry about ESMF calculating them. I'll leave this awhile to see if that changes.