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 https://github.com/Exawind/amr-wind/issues/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.