First take at encapsulating Resolve functionality

PathContext (should probably be ResolveContext), which maintains resolve state for a path (and its ancestors).
Yay, one successful test!

PathContext is created from a Path.  Paths have PathElements (based on states).   PathElements have a map of Resolvables.  Resolvables encapsulate the resolvable's resolveFn, the fn's declared dependencies, and a wrapped (.promise) and unwrapped (.data) result.  

Since Path contains Resolvables, which may or may not be resolved, it essentially manages the state for the entire path. 

~PathContext~ ResolveContext is the context in which a new resolve operation occurs.  ResolveContext is passed into Path.resolve(), PathElement.resolve(), or Resolvable.get() in order to satisfy the dependency requirements of the leaf nodes (Resolvables).

Resolvable.get() gets the Resolvable's existing promise, or else invokes the resolve() function on Resolvable and returns the resulting promise.

PathElement.resolve() resolves all the Resolvable at that path level.

Path.resolve() resolves all the resolvables in the entire path (curent ui-router behavior)

Individual Resolvables can be resolved against a PathContext, outside of a "block" resolve, such as PathElement.resolve().  Using this, we can make sure only the resolves we want are invoked before an onEnter, for example.

Once a transition is complete, the Path() should be built up from the existing paths' PathElement objects to create the next transition's PathContext.
I disabled loading of all other Specs