All doc updates forv15.5 (#9359)

* `react-addons-test-utils` -> `react-dom/test-utils`

Updating all references and docs on the `React.addons.TestUtils` and the
shallow renderer to refer to the correct targets.

Instead of:
```
const React = require('react');

// ...
React.addons.Testutils
// or

const ReactTestUtils = require('react-addons-test-utils');
```
we now show:
```
const ReactTestUtils = require('react-dom/test-utils');
```

And for shallow renderer, instead of:
```
const shallowRenderer = TestUtils.createRenderer();
```

we now show:
```
const shallowRenderer = require('react-test-renderer/shallow');
```

* Update the 'prev' and 'next' attributes of 'add-ons' docs

These flags are used to set arrow links to easily navigate through the
documents. They were wrong or missing in some of the 'add-ons' pages and
this bothered me when manually testing the updates from the previous
commit.

* Update syntax for instantiating shallow renderer

Missed this when updating the docs for the changes to shallow-renderer
in React 15.5.

* Fix pointers in addons docs

Thanks @bvaughn for catching this

* Make example of shallow renderer more consistent

We should show using the same variable names between code samples.

* Make names in example even more consistent

We should use the same variable name for the same thing across examples.
`renderer` -> `shallowRenderer`.

* Update docs to deprecate React<CSS>TransitionGroup

 - removes link to the docs about `ReactCSSTransitionGroup` and
   `ReactTransitionGroup` from the main navigation
 - updates 'prev' and 'next' pointers to skip this page
 - adds deprecation warning to the top of the page
 - remove references to these modules from the packages README
 - updates 'add-ons' main page to list this as a deprecated add-on

* Update `React.createClass` to `createReactClass` in the docs

The `React.createClass` method is being deprecated in favor of
`createReactClass`.

* Remove 'React.createClass' from top level API docs

It no longer makes sense to have a section for the 'createClass' method
in this page, since it won't be available as a top level method on
'React'.

I initially was going to pull the section about 'createClass' into a
separate page to add under 'addons' but it was short and duplicative of
the 'react-without-es6' docs. So I just linked to those.

* Remove *most* `React.PropTypes` from the docs

I am doing the docs for `context` in a separate commit because that case
was a bit less clear-cut.

We will no longer support `React.PropTypes` as a built-in feature of
React, and instead should direct folks to use the `PropTypes` project
that stands alone.

Rather than retaining the `React.PropTypes` examples and just revamping
them to show the use of the stand-alone `PropTypes` library with React,
it makes more sense to direct people to that project and reduce the
perceived API area and complexity of React core. The proper place to
document `PropTypes` is in the README or docs of that project, not in
React docs.

* Update `context` docs to not use `React.PropTypes`

We use `React.PropTypes` to define the `contextType` for the `context`
feature of React. It's unclear how this will work once `React.PropTypes`
is replaced by the external `PropTypes` library. Some options;

a) Deprecate `context`, either in v16 or shortly after. Seems reasonable
based on the intense warnings against using context that we have in the
docs -
https://facebook.github.io/react/docs/context.html#why-not-to-use-context
**Except** that probably some widely used libraries depend on it, like
`React-Router`.

b) Expect users will use external `PropTypes` library when defining
`contextTypes` and just don't do our `checkReactTypeSpec` against them
any more in v16.

c) Stop masking context and pass the whole context
unmasked everywhere. Worst option, do not recommend.

I went with `b` and assume that, for now, we will get users to use the
external `PropTypes` when defining context. I will update this PR if we
want a different approach.

* Remove 'addons' items from left nav, and deprecate 'addons' doc page

The plan:
[X] Remove links to 'addons' items from main navigation
[X] Add deprecation notices where appropriate, and update syntax to show
using the separate modules.
[ ] Update other references to 'React.addons' in docs. Coming in next
commit.
--- blocked but coming in future PRs
[ ] Link to a blog post describing the new locations of add-ons in the
deprecation notice on the '/docs/addons.html' page. Blocked until we
actually publish that blog post.
[ ] Move the docs for each add-on to the actual github repo where it now
lives.
[ ] Redirect the old add-ons doc permalinks to the docs in the separate
github repos for those modules.
[ ] Remove the old add-ons doc markdown files from React core docs.

* Remove references to `React.addons` from docs

Just misc. places where we referenced the 'addons' feature. All gone!

docs/reference-react-component.md

@@ -31,7 +31,7 @@ class Greeting extends React.Component {
 }
 ```
 
-If you don't use ES6 yet, you may use the [`React.createClass`](/react/docs/react-api.html#createclass) helper instead. Take a look at [Using React without ES6](/react/docs/react-without-es6.html) to learn more.
+If you don't use ES6 yet, you may use the [`create-react-class`](/react/docs/react-api.html#createclass) module instead. Take a look at [Using React without ES6](/react/docs/react-without-es6.html) to learn more.
 
 ### The Component Lifecycle
 
@@ -73,7 +73,6 @@ Each component also provides some other APIs:
 
   - [`defaultProps`](#defaultprops)
   - [`displayName`](#displayname)
-  - [`propTypes`](#proptypes)
 
 ### Instance Properties
 
@@ -122,7 +121,7 @@ constructor(props) {
   this.state = {
     color: props.initialColor
   };
-}  
+}
 ```
 
 Beware of this pattern, as it effectively "forks" the props and can lead to bugs. Instead of syncing props to state, you often want to [lift the state up](/react/docs/lifting-state-up.html).
@@ -315,26 +314,6 @@ The `displayName` string is used in debugging messages. JSX sets this value auto
 
 * * *
 
-### `propTypes`
-
-`propTypes` can be defined as a property on the component class itself, to define what types the props should be. It should be a map from prop names to types as defined in [`React.PropTypes`](/react/docs/react-api.html#react.proptypes). In development mode, when an invalid value is provided for a prop, a warning will be shown in the JavaScript console. In production mode, `propTypes` checks are skipped for efficiency.
-
-For example, this code ensures that the `color` prop is a string:
-
-```js
-class CustomButton extends React.Component {
-  // ...
-}
-
-CustomButton.propTypes = {
-  color: React.PropTypes.string
-};
-```
-
-We recommend using [Flow](https://flowtype.org/) when possible, to get compile-time typechecking instead of runtime typechecking. [Flow has built-in support for React](https://flowtype.org/docs/react.html) so it's easy to run static analysis on a React app.
-
-* * *
-
 ## Instance Properties
 
 ### `props`