Consistent use of turbine indexing when coupled to c/c++

[andrew-platt]

This is ready to merge, pending discussion.

Feature or improvement description
There has been an ambiguous usage of turbine indexing. In C and C++ codes, arrays start with index 0, but Fortran starts with index 1. In coupling OpenFAST to AMR-Wind, an array of Turbine data structures was created spanning from index 0:NumTurbines-1. Indexing into this array has been handled by the iTurb variable passed into all routines in FAST_Library.f90 that include a c-bindings interface. However, inside the FAST_Subs.f90 file, this turbine index is assumed to run from 1:NumTurbines for compatibility with FAST.Farm.

This PR corrects the following:

1. Change the variable ExternInitData%TurbineID to ExternInitData%TurbIDforName to more accurately reflect the usage of this variable. This variable is only ever used to set the name of the output file (i.e. SimName.T0.out). This variable must be 0 or larger (new error handling added).
2. FAST_AllocateTurbines now allocates the Turbine data structure to the range (1:NumTurbines).
3. All routines in FAST_Library.f90 that include a c-bindings interface now take the argument iTurb_c instead of iTurb. This is the index to the turbine using the c-style array indexing starting at 0. Internally this shifted by 1 and stored as iTurb, a Fortran index starting at 1.

Since the output names are set using the TurbIDforName variable, the name is completely independent of the internal numbering.

Related issue, if one exists
Exawind/amr-wind#984
#2096

Impacted areas of the software
This will affect any codes calling OpenFAST using the FAST_Library interface using 1 as starting index for the first turbine -- these codes will need updating to use 0 as the index to the first turbine. This might affect NALU-Wind, and potentially SOWFA (I'm uncertain what interfaces those codes use, or what assumptions on indexing are made).

Additional supporting information
The only place this ambiguity of indexing appeared is when a checkpoint file was written or read. It doesn't appear that anything else was affected.

Test results, if applicable
This will require testing by @marchdf and possibly others.

[marchdf]

@andrew-platt thanks for working on this. I had to rebuild this whole amr-wind stack because they've changed the way we do builds on our end. Running into some snags with this new method and then I will be off the rest of the week. So realistically I won't be testing this until next week.

[marchdf]

I can confirm that the files are closed with these changes and interfacing with amr-wind. Thank you!