Add ComponentDefinition + Public model registry API

[lukelowry]

Description

Adds ComponentDefinition, which gives each model one place to describe its parameters, ports and monitorable variables: units, a symbol and a short description for each.

Closes #482. I originally proposed a schema or a manifest. This is the API version of that, and anyone who wants a JSON schema can generate one from it.

Proposed changes

• ComponentDefinition<...> in ComponentDefinition.hpp. One entry per enum value for each ComponentData enum. complete() checks at compile time that every value is present and described.
• IEEET1_DEFINITION in Ieeet1Data.hpp with static_assert(IEEET1_DEFINITION.complete()). The old enum comments moved into it.
• COMPONENT_DEFINITIONS and forEachComponentDefinition(visit) in ComponentLibrary.hpp. Registering a model is one line.
• Utilities::enum_name, an enum_name that is safe on empty enums, behind name() on each entry.
• Modeling checklist updated.

For example, listing every model and its parameters:

forEachComponentDefinition([](const auto& model)
{
  std::cout << model.device_class << '\n';
  for (const auto& parameter : model.parameters)
  {
    std::cout << "  " << parameter.name() << " [" << parameter.units << "] " << parameter.description << '\n';
  }
});

This gives some flexibility on consumer end which I would prefer.

Checklist

• All tests pass.
• Code compiles cleanly with flags -Wall -Wpedantic -Wconversion -Wextra.
• The new code follows GridKit™ style guidelines.
• There are unit tests for the new code.
• The new code is documented.
• The feature branch is rebased with respect to the target branch.
• The CHANGELOG.md has been updated to reflect the changes.

Further comments

Consumer applications really need this otherwise a priori information is required to develop with GridKit.

@pelesh Feedback on scope/size of PR is appreciated

[pelesh]

I think this needs more discussion. I am setting this to draft until we decide how to proceed. Having said that, this PR is very helpful and a good suggestion. More discussion in #482 is needed.

[superwhiskers]

based on my current read of this, i think that it duplicates too much from ComponentData. i'd prefer the two be merged rather than having two separate classes