At the same time we should rename and move MutatorHostClient to AnimationHostClient.

Will take this one as a warm up after a long vacation.

Actually mutator_host.h is included in lots of files under cc/trees/ [1]. Given that including cc/animation/ is forbidden under cc/trees/ [2], the interface MutatorHost seems to be necessary.
[1] https://cs.chromium.org/search/?q=mutator_host.h+file:%5Esrc/cc/trees/+package:%5Echromium$&type=cs
[2] https://cs.chromium.org/chromium/src/cc/BUILD.gn?l=355

Unless we choose to move animation_host.h to cc/trees/, I'd like to close this bug for now.

The code as currently structured allows cc/animation to depend on cc but not the other way around. In another word, cc/animation is the higher level library that is using cc as the lower level library. 

For example the MutatorHost is the abstract interface the cc understands and it is implemented by cc/animation and injected into cc. So cc does not need to know about AnimationHost. I did some digging, and most of the current structure of the code comes as a result of loyso@ work on  issue 575053 .


I think there is two paths to change this:
A) Remove the distinction between cc and cc/animation components.
B) Reverse the dependency direction i.e. have cc depend on cc/animation and directly use AnimationHost and remove cc/animation dependency to cc/

Not sure if A is any better than what we currently have.
B seems reasonable (and perhaps desirable**) but it requires some deeper clean up. In particular cc/animation has dependency in cc/trees that needs to be refactored and abstracted away.

Is there any other option I am missing? 


** In the past we have talked about re-using cc/animation code e.g. in VR animations without having to care about rest of cc, e.g., active/pending trees etc.