Refactor VictoryTransition and animations

This is a larger issue designed to cover a few individual bugs and issues that have been raised around Victory transitions. I'm just linking to all of the issues here since there have been a lot of issues around this recently, and I'm trying to prioritize our issues and cut down on some of the duplicates. Before these can be addressed, we should consider refactoring `victory-transition.js` and overhauling how transitions and animations are handled.

I am currently marking this as on hold until we can have more discussions about how we want to break up this work.

Issues to address:
- Slowness introduced by re-rendering when data interpolates (#847)
- Enter and exit transitions (#246, #531)
- Unexpected data mutation (#770)
- Configuring delays (#848)
- Support for custom data components (#973)

## Technical notes:

Because of the performance concerns around re-rendering every React component many times during each transition state, it might be a good idea to consider a d3-based approach that mutates the DOM without re-rendering every React component. In [her d3 + React course](http://shirleywu.studio/react-d3/), Shirley Wu discusses the division of responsibilities between React and d3, and the advantages of allowing d3 to control DOM rendering in some specific circumstances, such as during transitions. [use-d3-transition](https://betterprogramming.pub/d3-animations-in-react-with-1-line-of-code-976396a45ede) is an example of how we might cede this responsibility to d3 instead of React to simplify our code and reduce React re-rendering cycles.