[release/v1] Rules for "flag", "index", and other similar control variables

[mkavulich]

We have vaguely discussed a plan for handling "flag" variables, which I've been treating as a category including all variables that are specific to model code or other logical controls rather than physical quantities. This can include a number of possible variable types, often (but not always) indicated by a prefix:

1. Boolean indicators for whether a scheme, section of code, or other option is being exercised, or condition is met. Prefixes include flag_for_, do_, is_
2. Integer index of a particular list, table, or other data structure controlling code execution, file read/write, or other.... Prefixes include index_of_, control_for_, identifier_for_

The plan is to separate out all of these "control variables" into a dedicated section, with dedicated rules setting out their naming conventions, since these variables often do not fit neatly into the schema we have developed for naming physical quantities.

[mkavulich]

@grantfirl @gold2718 @climbfuji I am trying to document the history and usage of these prefixes, and I hope you can help me with some context if I'm missing it. In the current rules, only two types of control variables are described: logicals with the prefix flag_for_, and integers with the prefix control_for_. However, as documented above, the current names have a wide variety of similar variables with different names. This seems to have mostly come from PR #13 where a large number of flag variables (though not all) were changed from having a flag_for_ prefix to either do_, is_, or disable_, and many control integers were likewise changed from control_for_ to identifier_for_. The rules were not updated to go along with this change, but I think from the context I can figure out some rules that should be added:

Prefix	Type	Use case	Example
flag_for_	logical	A flag indicating some state or condition is true or false	flag_for_mpi_root indicates whether or not the code is running on the MPI root process
do_	logical	A flag whose value directs some behavior	do_chemical_tracer_diagnostics indicates to a physics physics scheme that it should compute chemical tracer diagnostics
identifier_for_	integer	A parameter indicating some state or condition	identifier_for_noah_land_surface_scheme an integer identifying the Noah land surface model
control_for_	integer	A control whose value directs some behavior	control_for_land_surface_scheme an integer identifying the land surface scheme type
index_of_	integer	An index entry for an array	index_of_cloud_condensation_nuclei_number_concentration_in_tracer_concentration_array Index describing the location of cloud condensation nuclei number concentration in the tracer concentration array

I think that is_ is redundant to flag_for_, and disable_ (which only appears once) could be replaced with do_disable_.

Does this sound like a good understanding of the current usage of these prefixes? I welcome any changes to unclear or incorrect wording. Also, is there anything that should be updated/changed?