Refactor environments and restoring

[croaky]

Continue to not allow Parity to accidentally modify the developer's production
database.

[croaky]

@geoffharcourt @gabebw @derekprior Any of you have a moment to review this change?

I noticed that there was some unnecessary repetition in these files. I it almost a true refactoring. It changes the error message for when a user tries to restore a backup into their production database, which I explicitly don't want to support for paranoid reasons of potentially feeling awful for making it easy to mess up someone's production data.

[geoffharcourt]

+1 on preventing overwrites on production. I have had some cases where I've wanted to test data changes and then push those changes to production once I felt that they were working on staging, but I've settled on http://github.com/harrystech/seed_migration for that functionality instead.

[geoffharcourt]

If no one else using the gem has more than one environment that they are worried about overwriting, then I think the suggesting refactoring with the conditional for production is OK.

I only have one environment that I am worried about overwriting (production), but if developers have more than one production environment (we considered treating our demo environment as production-ish, for example) one approach I could see here would be to have two classes, Parity::Environment and Parity::ProductionEnvironment, the difference being that ProductionEnvrionment doesn't allow #restore. Unless any of you have an actual app in a situation that would require this approach, then I think it's better to proceed as @croaky suggests.

[croaky]

Okay, cool. Thanks, @geoffharcourt. Yeah, I don't know of projects that we have like that.