Documentation overhaul

[kyriakosTapinou]

Imperative to usability @kyriakosTapinou this is your responsibility for the basic stuff.

• Order logically/conceptually the inputs and problem generator file documentation. Categorise as (i) AMReX inputs (ii) cerberus inputs (iia) helper functions (iib) non-dimensionalisation (iic) states (iid) actions (iii) embedded boundaries - needs its own section
• Documentation for each test case
• Documentation for user defined functions e.g. sources and other
• Documentation for developers e.g. tips, tricks, for contributing and making changes

[bezmi]

I've made significant changes to the lua inputs so that more of the amrex options in the .inputs (grid sizes, amr levels, etc) can alternatively be set within the .lua file instead. Just something to keep in mind. I've kept everything backwards compatible though, so any instructions you put in the docs will (famous last words) still work with my changes. Just waiting until I have a block of time to document all of my code changes properly in a pull request before I merge them.

When you do write documentation, use github flavoured markdown and put the file at doc/DESCRIPTIVE_TITLE.md. For the test cases, the documentation should be a simple README.md in the respective directory (Exec/testing/Thermal-RMI/README.md for example).

Using markdown will allow inclusion of images, code blocks, latex math, tables, footnotes for references, etc.

On a related note, we should (one day) set up a docs webpage using the mkdocs-material framework. If we use markdown for everything from the get-go, it will be as easy as copy/pasting the existing files from this repo into the 'test cases' section for the documentation site.

[bezmi]

Also, would be good to edit your original post in this issue and use the 'task list' button to add a list that we can use add items that need doing and check them off as we go.

[kyriakosTapinou]

I've updated the wiki, is there a feature to auto move these to the doc/ dir?