Deallocate stack resources after app deletion from deployed environment.

Currently the only way to deallocate OS resources, allocated for murano environment, is to delete the environemt itself. This is highly inconvenient and leads to resource leaks. This blueprint proposes to improve this situation, by improving the way app deletion is handled within murano-engine code.

Known challenges:
1) Current HeatStack-API is not very well suited for incremental updates/deletes, because it treats heat stack as a single object, therefore there is no API for CRUD of a single Heat-resource within that stack. This makes it problematic to track any resources, that might be shared between different applications.
2) Currently apps can define a destroy method, that would be called by murano-engine's garbage collector on app deletion. The order of calling these methods is significant. We can imagine a situation, when App1 requires (is hosted by) App2 and App2 has Instance as its parameter in Object Model. In this case App1 delete should probably called before App2, because after App2 was deleted — there would be no instance to remove App1 from.
3) Cyclic references (although not yet allowed in muranopl obj model) should be though of.

Several options exist on how to solve the problem:
1) We can add Meta-data to MuranoPL parameters (references), which would allow application developers to somehow specify the order of deletion
2) We can add garbage-collection API to MuranoPL, that would allow application developers to influence the order of deletion of applications. For example Host application can request an extra pass of garbage collection and remove itself from current pass if there are dependant packages, that have to be removed before it is removed.
On a side note: In some cases it may be OK to not call destroy for the hosted app if it was removed together with the host itself. (We could enable application developers to specify this behaviour.)

These approaches can be even combined in some fashion.

There is also a related issue, regarding stat synchronization between Objects and ObjectsCopy in Object Model when performing a destroy action. Currently destroy would reference objects from ObjectsCopy and it could change some internal state of the ObjectsCopy model, but consequent deploy would use Objects as it's reference model.