[Docs]: Proper Plugin Development Documentation

[Mcrich23]

Feature or enhancement request details

This issue is a beginning of a discussion to draft new documentation for developing plugins for container. This will build on #603, #571, #625, and #717.

Code of Conduct

• I agree to follow this project's Code of Conduct

[Mcrich23]

@jglogan Bringing this issue to your inbox.

[Mcrich23]

Here is my rough idea of an outline for documentation. Thoughts before I begin?

Developing A Plugin

Integrating with high level commands

Passing down OptionGroups

Working directly with the APIs

Submitting A Plugin

Adding a plugin to the makefile

[Mcrich23]

@dcantah @katiewasnothere thoughts before I proceed?

[katiewasnothere]

@Mcrich23 Might be nice to have a section on like "using a plugin" from a code perspective. To answer the question of "how do I call into my plugin once it has been loaded". But otherwise, this looks good to me. Thanks for looking into this :)

[mon2000x111-sketch]

8b79ec5

[Mcrich23]

@katiewasnothere I would love to wrap out this documentation, but I need to get #717 merged before this can be fully written. The PR will make it easy for plugin developers to pass down all of the arguments from an OptionGroup inside Flags into the call to a command. It automatically generates the function at compile time, which reduces the overhead for maintenance of the functions in the future. It also means that simply pulling the latest changes will update a plugin to support new global flags used by commands called by the plugin.