Prepare new composite child before removing old (#8572)

This matches what we do in Fiber -- and doing it this way is the only way we can prepare new views in the background before unmounting old ones. In particular, this breaks this pattern: ```js class Child1 extends React.Component { render() { ... } componentWillMount() { this.props.registerChild(this); } componentWillUnmount() { this.props.unregisterChild(); } } class Child2 extends React.Component { render() { ... } componentWillMount() { this.props.registerChild(this); } componentWillUnmount() { this.props.unregisterChild(); } } class Parent extends React.Component { render() { return ( showChild1 ? <Child1 registerChild={(child) => this.registered = child} unregisterChild={() => this.registered = null} /> : <Child2 registerChild={(child) => this.registered = child} unregisterChild={() => this.registered = null} /> ); } } ``` Previously, `this.registered` would always be set -- now, after a rerender, `this.registered` gets stuck at null because the old child's componentWillUnmount runs *after* the new child's componentWillMount. A correct fix here is to use componentDidMount rather than componentWillMount. (In general, componentWillMount should not have side effects.) If Parent stored a list or set of registered children instead, there would also be no issue.