Discussion: Report detailed results of creation, deployment

**Perceived problem:**

Currently, the solution-creation entry points `creator.createSolutionFrom` return the created solution's item id, and the solution-deployment entry point `deployer.deploySolution` returns a structure with the deployed solution's item base and data. Some errors during creation appear as a property in the template for an item; other errors--and errors during deployment--terminate the process. (cf. #122)

Solution creation has one or more of the possible results
1. Solution and all of its items and their dependencies successfully become templates
2. Solution itself cannot be created
3. One or more items fail to become a template; e.g., failure to fetch item, failure to templatize item
4. One or more items are an unimplemented item type
5. One or more items cannot be--or should not be--templatized because they are external to the solution, e.g., well-known map services

Solution deployment has one or more of the possible results
1. All items and their dependencies successfully deploy
2. One or more items fail to deploy
3. One or more well-known external items don't exist in target environment, e.g., disconnected environments

In order to help creation and deployment apps provide usable information to the user, this issue proposes to modify the results from the entry point functions to include information that client apps can choose to use.

**Proposed implementation:**

For creation and deployment entry points, return an expanded JSON structure composed of:
* Solution item id; empty if solution cannot be created or deployed
* Errors: a list of all items with templatization or deployment errors, including unimplemented item types
* Warnings: a list of all items with templatization or deployment concerns, such as external content

Change all error and other issues into a property in the template for a templatized or deployed item instead of halting creation and deployment. At the end of solution creation or deployment, we have a JSON list of items in template or deployed form, respectively. We filter out errors and warnings and only write successful items into the solution item. The creation and deployment entry points return the filtered-out errors and warnings along with the id of the solution template or deployed solution item.

Currently, unsupported item types are filtered out and discarded, and I propose keeping it that way.

**To do**

How do we handle dependency references from valid items to errored items? Because the problem items will exist in the internal item list but with a fault flag and dependencies are templatized or deployed before dependent items, dependent items have the information to delete references to the problems. But the resulting solution template or deployed solution may be rendered useless without, say, a key map or feature service.

---
@shoe913, @chris-fox, @jmhauck, @cosbyr, comments?