CLN: Remove unused 'multiple model' functionality

[NickleDave]

In theory the config allows instantiating multiple models for training / prediction but this was never fully implemented and to make it really work is more trouble than it's worth I think

I thought I had raised an issue about this before but not finding it

This should be one of the things that's a clean-up step before adding new functionality

[NickleDave]

Doing this should fix #353

Read discussion on that issue to be sure

[NickleDave]

Should probably do this in 1.0 because changing option "models" -> "model" would be a breaking change.
We might as well just introduce the new config format at the same time.

[NickleDave]

Started to work on this while working on #624 to fix #601 but there's a couple different things tied up in it.

One is just removing the functionality.
The other is what to replace it with.

The latter is tied up with how we pass models from the cli functions to their corresponding core functions, which I'll describe now, since it shows how the replacement could get complicated down the road when we try to add more functionality.

How we do things now

Currently the way we do this is quite convoluted.

• Currently we accept the option models in the train, eval, learncurve sections. We convert this option to a list (which always has just one element, the one model name)
  • There's a converter, comma_separated_list, that takes the string we always pass in and makes it such a list, e.g. "tweetynet" -> ["tweetynet",] (even though the logic for iterating over more than one model never actually worked as stated above)
• Then inside the cli functions that involve models (i.e., train, eval, learncurve, predict, but not prep) we pass this "list" of model names ( a single name) to config.models.map_from_path along with the toml path. This is because we need to find the corresponding config section since we don't leverage the TOML format very well.
• We get back a dict mapping model names to a config in the form of a dict, with keys 'network', 'loss_func', etc. But again this dict only has one key, a single model name, that maps to a single config
• We then pass this dict into a core function from its respective cli function
• Then inside the core function we need to call another function to actually get the model instance: vak.models.models.from_model_config_map
• This is because there is logic inside the core functions that create things we actually need to instantiate the model; in other words, there are required arguments for vak.models.models.from_model_config_map that we won't have until we've done some set up
  • E.g., we need to know num_classes, and the way we do this is by creating a labelmap from the labelset of the config.
• So we can't just call the function vak.models.models.from_model_config_map outside of the core function and then pass in an already-instantiated model

What to replace this with?

• we could factor out all the set-up logic inside cli; basically inside of the cli it should be like a script written for the most common workflows. I thought I had written this somewhere but the closest quote I find is:

The key idea for any cli function should be "what is the most common / generic workflow for a user; capture that in code".
So if it doesn't look very much like something a user would want to write, re-factoring / abstraction needs to happen

from #359 (comment)

Two issues with just factoring out all the set-up logic though:

• What happens when we have more than one workflow? We're going to want to abstract that out into other functions somehow, e.g. windowed_frame_classification_model_setup.
• If we factor everything out of core that's set up, there actually won't be anything left in core! One would pass in model along with dataset and then call trainer(model, dataset). So basically instantiating a trainer would be in there? And maybe not even that should be in there, if we're going to have multiple workflows, each will need its own trainer set-up logic.

So, need to think about this more. Will probably raise a separate issue planning it out.

[NickleDave]

Okay so here's a way to get this done for now:

• Rename option "models" in config sections to -> "model", validate. We can handle the new config format later
• Rewrite vak.models.models.from_model_config_map as just vak.models.get(name, config). We can just keep the vak.config.models.from_toml_path logic for now that finds the corresponding model section in a config file.
• Add parameters model_name and model_config to the core functions. Then we call vak.models.get with model_name and model_config.

Then we worry about all the refactoring stuff in the comment above, later.