[plugins] Add support for plugin options to customize plugin behaviour

[sbordeyne]

Is your feature request related to a problem? Please describe.

k9s plugins are great but lack customization options. For instance, it would have been nice, in the start-alpine plugin to:

• Add an option for root/non-root execution
• Add options for container presets with initContainers (installing common tools for instance)
• Add options to set annotations/labels for networkpolicy matching

Describe the solution you'd like

Currently, k9s has the ability to show dialogs, when scaling a deployment, port forwarding and so on. I'd like to be able to define, in the plugins.yaml, a dialog to customize variables sent to my plugin context

The options dialog could be defined as such:

options:
  runAs:
    type: select
    name: "Run As"
    choices:
       - root
       - nonpriviledged
    default: root
  extraLabels:
    name: "Labels"
    type: string
    default: ""
    match: "^\w+(,\w+)*$"  # Useful to validate the string before submitting
  replicas:
    type: int
    name: "Replicas"
    min: 1
    max: 3
    default: 1
  preset:
    name: "Preset"
    type: select
    default: "none"
    choices:
      - none
      - tcpdump
      - curl
      - bind-tools

Such a feature would also be handy for logs (there are plenty of log related plugins, for jq parsing, loki, raw etc) which could all be merged into a single logs plugin.

The values for the options should be retrieved as environment variables. Of course, it should be dissallowed in the plugins.yaml schema to add options for the CONTEXT, NAMESPACE and other default environment variables for the plugins, in order to avoid conflicts. To keep it clean and maintainable, one could also enforce plugin options to be injected as env variables, prefixed with the name of the plugin, for instance if the above example is for the start_pod plugin, the preset option would be accessed through the START_POD_PRESET environment variable, limiting the risks of collisions.

As with the above example, validation would be appreciated (so that you cannot submit invalid options), though not strictly required as an alpha feature.

This feature could later be expanded further for other types of options (bool comes to mind, select with autocompletion, multiselect) or even be expanded to save the last options sent to a plugin as the default values.

Describe alternatives you've considered

The only alternative is to duplicate the plugins for different use cases (which get difficult to manage after a while, especially with managing conflicting keyboard shortcuts)