Improve prune feature implementation

[fgiloux]

Feature Request

Is your feature request related to a problem? Please describe.
It seems that the implementation of the prune feature could be improved. As part of the fix for PR #100 I noticed the following:

• Naming issue: Config is the main struct for the prune logic, which leads to methods like:
  Config.Execute. It does not sound right. Config may be passed to a factory creating a Pruner or a Processor structure but the Execuste method should be on the later structure: Pruner.Execute() or Processor.Execute() makes more sense.
• The Config structure seems not optimal in the sense that for instance the same Strategy has to be applied to all the resources. If the logic is to be configured once for multiple resources it may make more sense to have a slice or a map of substructures containing the specificity for each resource: gvk, namespace, strategy, pre-deletion hook. A different strategy can then be selected by the user for each resource.
• The ResourceInfo structure seems to be limiting. Using Unstructured would allow working with any type. The additional logic would then be able to work with fields specific to the type being processed.
• The pod deletion strategy only considers succeeded pods. It should also consider failed pods. Basically all pods with the terminated state, possibly letting the user selects the phases that are candidates for pruning.
• It may make more sense to use a closure for strategy rather than a structure strategyConfig and a func StrategyFunc. By doing so it would be possible to unify the interface for what is implemented by the library: pruneByMaxAge, pruneByMaxCount and what is provided by the user: CustomStrategy. They would all be a func, possibly passed as a Config field with this signature:

  func pruneStrategyt(resources []unstructured.Unstructured) (resourcesToRemove [][]unstructured.Unstructured, err error)
  

  Specific parameters part of the Config would be made available through closure variables. pruneByMaxCount would then not need a Config.strategy, which provides information meant for all possible strategies. It would make things easier to extend and the implementation would be more performant: No need for switch config.Strategy.Mode in prune.go. All the prune strategies would have the same signature.
• The context is passed to the functions in the library but my feeling is that we have two use cases:
  • The prune logic is called from a reconciliation loop and the context may provide more information
  • The prune logic is called from a cron job (as per the documentation) and the context will provide little information
    I haven't seen it really used. Is it thought more as a safety net (if anything is needed that was not foreseen get it through the context)? Can this be addressed through the closure approach?
• We should also aim and I believe the points listed above would help with that not to limit the logic to pods and jobs.

[fgiloux]

cc @ryantking @gallettilance @jmrodri