Plugin configuration

[johnharris85]

Describe the problem/challenge you have
As a plugin developer, I may need to read some local (or remote?) configuration to setup my plugin (credentials, endpoints, etc...). Right now I would make some code to deal with getting this from disk, parsing it, etc... Not a huge amount of overhead, but applicable to a lot of future plugin developers probably.

Describe the solution you'd like
Some 'standard' way of Octant enabling plugins to read configuration which is then exposed to the plugin via an 'options' struct / function etc... It would deal with parsing from a set location (maybe ~/.config/octant/plugins/plugin-name.{json,toml,yaml}), dealing with missing fields or whatever, and then exposing this in a friendly API to the developer for use.

[wwitzel3]

This potentially related to #557

I like the idea, but at the moment, I just don't think there is enough information to make an informed decision about how this would be implemented.

Implementing something like this is essentially creating another external API surface for us to maintain and version. The likelihood that plugins will want to store and load and use this data in radically different ways seems pretty high.

I think this maybe a great case for establishing a convention in the documentation around plugins, providing some clear examples, and letting plugin authors implement this in a way that best works for them.