[Developer Issue]: Relocate and document FIMS folder descriptions

[Bai-Li-NOAA]

Description

As discussed in the pull request #148, we will move the description of FIMS folders from the 07-contributor-guide to the FIMS repo using Markdown files. The Markdown files can be automatically rendered in a vignette as child documents for training purposes.

Tasks

• [ ] move the description of FIMS folders to the FIMS repo using Markdown files
• [ ] Write a vignette to list all Markdown files within FIMS/inst/include (e.g., markdown_files) and then render the files using the following code:

  ```{r child = markdown_files}

[kellijohnson-NOAA]

@Bai-Li-NOAA will help with vignette. Need someone to write documentation.

[kellijohnson-NOAA]

I am copying and pasting the documentation that was in the collaborative workflow that will need to be moved to README.md files so it is not lost.

common

This folder includes files that are shared between the interface, the TMB objective function, and the mathematics and population dynamics components of the package.

interface

This includes the R interface files.

population_dynamics

Each folder in population_dynamics corresponds to a component of the population dynamics model. Given the complexity of the component, the structure in these folders within population_dynamics may differ. At a minimum there will be a .hpp file with the same name as the subfolder, e.g., fleet/fleet.hpp. This file will include an ifndef directive and #include statements. If the folder is empty other than this file, then the remainder of the file will define the component. If there are additional subdirectors along side the .hpp file, the file will end after the include statements that point to each of the files in the functions folder that sits next to this .hpp file.

For the latter scenario, where a functor folder exists, inside the functor folder will be a .hpp file with _base attached to the component name, e.g., population_dynamics/maturity/functors/maturity_base.hpp. This _base.hpp file will define the base class for the module type. The base class should only need a constructor method and a number of methods (e.g., evaluate()) that are not specific to the type of functions available under the subfolders but reused for all objects of that class type.