Add support for a depth_in_ancestor tag and simplify spec_hierarchy tags

[ahgittin]

Adds depth_in_ancestor which lets us see how far up in the hierarchy we need to go to find the blueprint which caused an entity to exist. eg if a type X declares children A, B, and B with child C, then A and B have 1 and C 2. this remains true even for A,B,C inside an X is used in another blueprint, and in that case X will have whatever depth it has in that blueprint. depth_in_ancestor is not defined for a deployed blueprint application root. So if when looking at an entity you want to see which blueprint declared it, look at the spec_hierarchy on the ancestor depth_in_ancestor levels up. (In particular if depth_in_ancestor is equal to the depth in the live deployment, then the entity was included in the root deployment.)

Also switches recent yaml_spec_hierarchy to be called the simpler and better spec_hierarchy and to use single-key maps eg

spec_hierarchy: [ { summary: "original", contents: "plan" } ]
depth_in_ancestor: 1

instead of the more (and unnecessarily) complicated {kind: spec_hierarchy, contents: [ { summary: "original", contents: "plan" } ]

kind is still used for named strings, so as to minimize disruption, but going forward named keys are much simpler

[iuliana]

@ahgittin Will this still be compatible with the UI changes?

[ahgittin]

@iuliana yes, the API doesn't change, it always returned a list of spec summaries

[iuliana]

@ahgittin awesome then. That means in the UI we only need to tweak the refresh rates in the app inspector.