Comment 1 for bug 1660608

This is a distinction that has caught me out several times, and I think it needs fixing. There are pros & cons for using only a stage-specific file vs. updating collect to behave like deploy.

Removing inheritance from deploy (and possibly other phases?) requires:
- Add facility to include other files within deploy configs
- Remove all but the stage-specific configuration from call to juju-deployer
- Update IS-owned specs to account for this
- Announce this to mojo-announce as a backwards-incompatible change
The risk with this is that it holds the possibility that specs could deploy 100% correctly in CI, including passing all their Nagios checks, and yet still be incomplete because they were depending on the common deploy config to deploy a significant portion of their application units.

Updating collect to behave like deploy requires:
- Add a facility to exclude a collect which has been previously included; this could probably be as simple as prefixing the line with a dash
- Update collect phase to collect from all applicable files; this could be as simple as multiple calls to codetree
- Review IS-owned specs to see if any changes are needed
- Announce this to mojo-announce
The risk is that some charms will be collected when they aren't needed; if they're not referenced in the deploy config, this seems harmless enough.

Another option would be to deprecate stage-specific collect/deploy files entirely, and use conditionals within the master versions. In general, I've found this to result in more comprehensible specs with less duplication.

Next step: make a decision about which direction to go.