Sections: Generalisation of today's model inputs

[pinkwah]

We have two kinds of model inputs: concentrations and parameters. These are implemented independently in both the frontend and backend. These have worked reasonably well, but they're rigid. Despite their functional similarities, they are different codepaths.

Both have unique functionality:

1. Concentrations have a dropdown that allow the selection of additional substances.
2. Parameters support more than just a number input box with fixed input range and descriptions.

We've also discussed that we should divide up sections. Maybe the temperature and pressure could always be present with its own heading, and maybe some parameters really ought to be under a "tweaks for advanced users" to reduce user confusion.

With that in mind, I present:

Sections

In addition to the input ID, each form input should have a section field. Each input belongs into a section. For each model info, we return a sections and inputs field. inputs is contains most of what today's parameters contain. That is, it's information about what each input does.

The sections field is a list of objects with the following information:

Field	Type	Description
key	string[]	Unique identifier
title	string	Text to put above each section

The inputs field is an extension of the parameters data and is approximately:

Field	Type	Definition
key	string	Unique identifier of the input within a section
sectionKey	string[]	Which section this belongs to
showByDefault	boolean	Whether this input should be visible by default or in the dropdown, a-la today's concentrations
label	string	Label of the input
...	...	...

Here, the sectionKey is a unique prefix for each section, and allows for model adapters to specify multiple sections. In addition to some built-in sections, like "concentrations" and "parameters" (for T & P), we can have ["arcs", "runOptions"] and ["tocomo", "runOptions"] without interfering with each other.