Make unmodular code generation a bit more unmodular

[balacij]

Contributes to #1999, #3247, #3512

Not quite ready to merge yet, but, this PR makes the Unmodular code generation choice a bit more unmodular by removing the generated function calls in favour of inlining them.

~~Three~~ ~~Four~~ Five major issues:

1. Code comments are completely removed from the unmodular option -- the comments that previously went above the function declarations.
2. Code needs to be tidied.
3. ODE-related things are untested.
4. GProc-generating code is untouched.
5. I have not tested generating derived inputs yet.

I'm also not quite sure yet how we should integrate this in the options. Should these changes go under Unmodular? SuperUnmodular? SpaghettiMonster? I currently have it editing Unmodular.

[smiths]

@balacij, this change should be helpful when we return to the human-readable code paper.

[JacquesCarette]

We want as broad a choice of "code families" as possible. So we should have ways to tune things, hopefully with somewhat fine-grained precision. So these changes should not remove previous possibilities, but augment them.

So we need sub-choices of Unmodular.

[balacij]

Converting to Draft because it needs to:

1. Be more careful. It should continue to generate functions for function-typed things.
2. Be split up.
3. Support GProc.
4. Get tested.

[balacij]

@JacquesCarette and I discussed this in our meeting yesterday. Paraphrasing our discussion:

• We want to move away from the "modular"/"unmodular" designations (as it is ambiguous/fuzzy).
• We want more concrete terminology captured/used/invoked when describing what kind of architecture.
• For example straight-line program could be an example (informally: just assignments, no ifs/fors/whiles) of a program we generate.
• Rationale: The story we would tell (in the paper) starts with the most "unmodular" version and shows how we can generate "more modular" versions (embracing the fuzzy wording here) through knowledge capture.

  Begin with the straight-line program, if we wanted to make it more readable, what would we do? Basically showing off Drasil's generation options and how we can gradually build "larger and larger" programs that describes more.

  Least verbose projectile to Most verbose projectile

• Side effect of the discussion: The responsibility of depth of knowledge capture can vary about the desired artifacts. For example, not all components of the SRS are strictly necessary to describe a program -- everything can be "junk" -- or, an entirely different SRS format can be used (a heavily stripped down variant of the SmithEtAl template). How slim down can an SRS get and still generate (reasonable) runnable code?