Distinguish user- from developer-facing docs

[wpbonelli]

General principle for flopy docs, but also pertinent to the MF6 IO guide. I am writing this here to solidify the thinking before potentially raising it in the context of MF6. We are already making this distinction in some places, but the IO guide contains some developer-facing concepts IMO.

People only using and not developing the program likely don't care (and shouldn't be forced to attend to) exactly how it works.

This is a more useful distinction when it comes to incidental complexity introduced by the program or platform, than details of the hydrological model. It's important for the modeler to understand how the model works, at least at a high level. But the system underlying the model consists mostly of implementation details. It should be presented to the user abstractly, not in the same terms developers use to implement it. (If there is a good reason for these to coincide, i.e. the developer concept is no more complex than the user concept, that seems fine though.)

For example, the IO guide describes array input in terms of "a generic READARRAY capability", frequently mentions Fortran concepts in the same section, and refers to the program's source code. These seem like developer-facing details — the user wants to know how to write correctly formatted input files, not what language the program is written in and what its internal routines are called. I understand the docs may be written with Fortran-familiar users in mind, but it seems like these details could go in a single dedicated section called "Notes for Fortran users" or something.

The section on binary output files also mentions Fortran concepts, describes file header string lengths in Fortran syntax, and presents Fortran pseudocode for iterating cells in DISV grids. IMO the former should be replaced with more general terminology, and the latter would be easier for many people to read in Python-ish syntax (I'm not saying remove the Fortran version though).

Also, the IDM/IDP machinery does not seem like a user concern, unless MF6 at some point supports different modes of memory management, potentially conditional on how input is provided (e.g., loading a full grid-sized array into memory rather than a sparse nodelist representation), which the user must be aware of to control performance characteristics. From the user's perspective, MF6 reads input files and simulates the conditions they describe. Using the program does not require knowing which components are read using IDP vs the old way. Differences in the timing of logging output seem appropriate for release notes and/or a brief mention in the IO guide, likewise for new ways IDM allows viewing variables in memory, but I think IDM/IDP details should go in developer-facing docs.