Move install logic out of private config processor and into install

[michaeltlombardi]

The ConfigProcessorI interface requires a valid interface to have two functions: CheckConfig() and ProcessConfig(). On inspection, ProcessConfig() is an install-only function which uses data returned from the currently private readConfig() function to determine behavior.

This functionality actually belongs in the install package as the function has to do with how a package is installed, not how a config is parsed/validated/read.

Acceptance Criteria

• [ ] ConfigProcessorI is updated to have ReadConfig() as a required function
• [ ] Turn readConfig() into a public function in the private config processor - work needs to be done to make the info returned by ReadConfig() a generic struct that can be shared; right now PCT requires the PuppetContentTemplateInfo struct and PRM requires the ToolConfigInfo struct - these are functionally identical, save for the PCT implementation looking for the template key and PRM the plugin key. Two options: first, update the keys for both to match (say, replacing template and plugin with meta - quick look at both pct-config.yml and prm-config.yml files shows that the data in these sections is about the package itself - it's id/author/type/display name/version/url/etc. The struct only cares about the top level key as other methods are used to retrieve the rest of the information; the second option is to figure out a way to handle expecting a generic object which could be either extant struct. Possibly useful is this blog on forcing a dynamic type
• [ ] Move the logic for ProcessConfig() and setupTemplateNamespace() into the install package as either a private or public functions
  • [ ] These should be updated, as
• [ ] Remove ProcessConfig() from the ConfigProcessorI interface
• [ ] Update tests as needed