Think about recursive removal

`View#remove` should be a reliable method, but right now it is ignorant of any idea of there being a nested view structure. Are there memory leak issues there? I need to think about how I want to handle the shutdown of the entire view tree.

`remove` plucks the element from the DOM tree and calls `stopListening`, so presumably I should do a few things at this point:
- Trigger an `onDetach` event down the whole tree (assuming the view was attached in the first place?)
- Call `stopListening` down the entire tree

Note to self: right now, each view has its entire tree in a collapsed form available under `_childViews`, which could be utilized in situations like this.

Start at View#remove and inspect how the collapsed _childViews tree is maintained. Review the existing stopListening behavior and determine whether onDetach already exists or needs defined semantics. Done means agreeing on and implementing reliable shutdown behavior for the entire view tree, including whether detached views should trigger onDetach.

Written by the indexing model from the issue text.