Update section and key names in config files for clarity and code usage

[asgibson]

The current section and key names in used by a configuration file are not consistent with each other or necessarily in line with how the values are used in production. Several updates should be performed to clarify usage.

Here are some ideas for the default_config.ini file:

1. 'parser' is an old moniker and DataSource should be used instead
2. [DEFAULT] is a catch all and should be dismantled into component parts
   a. the parser, now DataSource, should be renamed and perhaps put into its own section
   b. the files should go into a [FILES] section
   c. the plugins should go into a [PLUGINS] section
3. TelemetryMetadataFilePath and MetaFile should be consistently named
4. Required vs. optional keys should be clear
5. Optional keys should clearly indicate a default value used by the code if item removed
6. Sections, like [RUN_FLAGS] should be able to be optional if all its keys are also optional
7. [RUN_FLAGS] should be considered for rename, maybe [OPTIONS]
8. If renaming [RUN_FLAGS], update key name(s) to not use '_flags'

The default_config.ini currently serves as the example that user .ini files should follow. If that usage continues it should include everything, even all optional sections/keys. It may perhaps be better to create a "not for actual use" example for documentation on how to create an OnAIR config file. That example config could either be in addition to or replace the default_config.ini as the template for user's config files.

[dragonejt]

Hey, I've been pretty busy since sending you all the contributor form in January but have more time now to focus on this, and it looks like a good first issue for me to get started on perhaps. I assume that alongside updating default_config.ini itself I would also have to update how the file is parsed?

Tangentially, does the .ini data format have any standards? I was looking online and saw that it was used for a lot of Microsoft Windows configurations, but couldn't really find any references other than the python configparser docs. It does look very similar to TOML, has any consideration been given to porting the configuration over to TOML which seems to be much more used in modern-day python/configuration files?