The end of React-Hot-Loader

By this time we have reached limits of "hot replacement", and to overpass them we need something new. (Source issue : #1001)

The problem - there are so many ways to _DEFINE_ react component, what we could not handle all of them.

The major problems today:
- we are unable to replay all the changes. We knew only their result, not how they were made to repeat it. As result we could not _inject_ code updates into the existing components. It is easy to update StatelessComponents or prototype-based Class-Component methods, or bound arrow function, but not everything one could possible use.
For example:
```js
class App extends Component {
memoizedFunction: reselect(function) // <-- there is NO way we could "re-do" changes in `function`.
}
```
Unfortunately - this could become a common thing with latest React changes. Already did( #995, #978, #969, #984)
I've spiked 2 different implementation - babel and Proxy based - they could work, but this is not the things I would like to have, not the way I would like to go.
- we are changing types presented to React. Our greatest sideeffect. We have to wrap _original_ type with a proxy to maintain type equality in the future. We should try our best to avoid it. Cold components are good try, not not enough.

Just a two points, __we are unable to overtake__.
React-Hot-Loader could handle most of the React code, and would fit for almost any project. But we are stuck.

-----------------------------

I think React-Hot-Loader was a good spike, and it's time to more forward, and look to the way to to implement it __inside React__, stop hacking it, but start __being a part of it__:
- don't try to maintain the single proxyfied component, applying all the changes to it, but just "explain" to React that some components could be the same, even if `type` got changes, and transfer variables changed during lifetime (state, for example) from the old one, to the new.
Not trying to repeat the changes, but only to preserve state.

That will solve all the issues, and super simple to implement, as long we are already having everything we need for it, in the current RHL, but in much more complex form.

Something like `componentComparator` we spiked for Preact integration - https://github.com/gaearon/react-hot-loader/pull/960/files#diff-b26fdb1bb246da9739b0a423fbe9a65dR6, https://github.com/developit/preact/pull/1120 - just expose RHL internals about __compareAndSwap__, and that's all.
Probably it just a hundred lines for everything - changed properties tracking from _proxies_, class comparator from _hotRender_, and nothing more.

It should not be super complex to integrate this to React, as long there are only two location to hook into.

As result - we could drop instantly `hot-renderer`, and next drop componentProxy - two major pieces of RHL.

Start with source issue #1001 and the linked componentComparator work for the Preact integration. Read the existing hot-renderer and componentProxy pieces, then determine how their comparison and changed-property tracking could be exposed through React; done would mean preserving component state across type changes while allowing those pieces to be removed.

Written by the indexing model from the issue text.