Unify naming conventions for analysis/planning outcome messages.

[arthursloan]

There are a few cases I've run into where the naming conventions of things in analyzers and planners seem to clash.

1. Analyzer services takes an AnalysisRequest object and return an Analysis object while Planner services take a PlanRequest and return a PlanResponse object. We should either change Analysis to AnalysisResponse or PlanResponse to Plan make everything line up.
2. The Analysis object uses the field outcome for ARES outcome/status messages, while PlanResponse has the field planning_outcome. We should probably just make these both outcome.

The question now is how can we do this without breaking previous code, or at least adding in a depreciation message.

[nkleiner]

I think this is a scenario in which we can make some changes that are "breaking" in nature. For the purposes of addressing this comment, we only need to make changes to the PyAres library. Eventually I might have a burning desire to make these changes be reflected more directly in the data model, but ultimately they're simply to keep our naming a bit more consistent which is much more important to the average user than it is to the developers who have built the architecture. So what we can do is simply change the naming of these two items in the python library itself, which will give any PyAres users that consistent naming you're looking for.

Making this change directly in the code as a replacement WILL break scripts that update to the newest PyAres, but given this will be a PyAres change only they will continue to function on both the current and future version of ARES. Not to say people will never update PyAres, but they won't be prompted to unlike with ARES itself. And if they do update their PyAres version, their changes will be so minimal that I'm not sure it's worth blocking the swap for. Open to additional thoughts

[arthursloan]

Right now think I'm the one with the most PyAres modules, so I'd be the most impacted by a breaking change. I'd say its better to do this now before the external user base gets to big so if you don't have an issue with just making the change I'm in favor of going for it.

[nkleiner]

I've gone ahead and made the changes we talked about and linked the pull request. If you feel comfortable doing so feel free to check out the changes and provide comments as you'd like @arthursloan otherwise I'll likely just merge this in sometime tomorrow afternoon.

[arthursloan]

Looked over the changes. It all looks good to me!

[nkleiner]

These changes got merged in alongside a bunch of others in pull request #26 and will be part of the next release of PyAres