All of the install/delete/repo_hook stuff probably needs to be a touch more generic if
we want support for

- update an entitlement cert as now
- but generate say:
  -  a 'iso-downloader' config file
  - setup puppet to know where to get the newly available puppet repos
  - mvn config to use cdn's mvn repos

ie, there should some sort of ContentAccessConfiguration class/interface, so
yum/iso/mvn/kickstarts/whatever would be similar

For the ent cert cases, probably need a variant that can be created with the entitlement cert
(and it would know to look for say, the iso content blobs)

[future proofing might require that the ContentConfiguration classes would need to register
themselves with a mapper, if we expect to add types to the certs and provide client plugins for it]

That said, I'm also all in favor of making sure candlepin etc can just generate the whole effing content
config themselves (ie, send us a rendered "redhat.repo" to install on the system directly). Which would
make client side content type->thingThatUnderstandsWhatToDoWithThatContent unneccasary. 

[Or for the non hosted side, adding yum/mvn/whatever plugins that do it on the fly, without any need for local configs...]