Issue title: Document workaround for annotating bound methods in React components
 Issue body: AFAICT there's still no real solution for this problem:

```js
  constructor() {
    super();
    this.onToggle = this.onToggle.bind(this); // Flow error: Cannot assign `this.onToggle.bind(...)` to `this.onToggle` because property `onToggle` is not writable.
  }
```

The closest thing I can find to official guidance on this is a [comment](https://github.com/facebook/flow/issues/1517#issuecomment-194538151) from @samwgoldman recommending this workaround:

```js
    (this: any).onToggle = this.onToggle.bind(this);
```

The above-linked issue was closed with no solution, except the workaround given in that comment. I've had to go searching for that comment several times over the last couple of years to remind myself what's the 'official' workaround.

The [Flow docs for annotating React components](https://flow.org/en/docs/react/components/) still have no mention of binding methods on construction. I think it would be good to acknowledge this is a long term problem, and mention the binding issue and the workaround in the official docs.
 Comments: 
 Comment 0: I'm having this same issue. This is particularly annoying, and I don't know if it's just me, but it also messes up the syntax highlighting in my editor when I use this workaround.
 Comment 1: I have the same problem here. As josh-degraw mentioned, the workaround is causing other problems with the editor but even new flow errors such as "missing property" in class.

 Comment 2: I thought the recommendation was to declare your methods using property initialiser syntax?
```javascript
onToggle = event => { /* ... */ };
```
as opposed to
```javascript
onToggle(event) {/* */}
```
Have I misunderstood?
 Comment 3: @morcs yeah that seems like the best workaround (I didn't know about it when I posted this issue).  I think the docs should mention that too. But I think that is currently still 'proposed' syntax and needs the [transform-class-properties](http://babeljs.io/docs/plugins/transform-class-properties/) Babel plugin to work. So this should probably be noted in the docs, and it should probably also mention the other workaround (`(this:any)...`) for people who can't use property initialisers.
 Comment 4: if you have regular js classes, and in parent class you have this.f = () => {} 
In child class, you cannot call super.f();
 Comment 5: There's also this issue with arrow properties - you can't mock them in tests like this:
https://github.com/airbnb/enzyme/issues/1432#issuecomment-351670288
https://github.com/airbnb/enzyme/issues/1432#issuecomment-363889823
 Comment 6: You can let flow know that you want a class property writable with a type declaration for that class property. Example: 
```javascript
constructor() {
    super();
    this.onToggle = this.onToggle.bind(this);
  }

onToggle: () => void
onToggle() {
    // ... something something
}
```
 Comment 7: If you run into this problem because you're not using a build step, and using Flow's comment syntax, the solution provided by @kbui-prosper also works with [comment syntax](https://flow.org/en/docs/types/comments/):

```javascript
constructor(props) {
    super(props);
    this.handleClick = this.handleClick.bind(this);
}

/*38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5 handleClick: () => void */
handleClick(event /*: SyntheticEvent<HTMLInputElement> */) {
    // ... something something
}
```
 Comment 8: As another alternative, I prefer the slightly terser alternative, which means you don't need to worry about re-typing your method definition in a type declaration:

```
constructor() {
    super();
    this.onToggle = this.onToggle.bind(this);
  }

onToggle: Function;
onToggle() {
    // ... something something
}
```
 Comment 9: Is there a way in flow to import a class annotation like this contrived example?
```
type class Comp = {
  props: {
    name: string,
    label: string,
    onChange: (event:SyntheticEvent<>) => void,
  },
  state: {
    active: boolean,
  },
  handleKeyPress: (e: e:SyntheticMouseEvent<>) => void,
};

class TextButton:Comp extends PureComponent {
  constructor(props:Props) {
    super(props);
    this.handleKeyPress = this.handleKeyPress.bind(this);
  }
  handleKeyPress(e) {
    if (e.key === 'Enter') {
      this.props.onChange(e);
    }
  }
  render() {
    return (
      <button
        name={this.props.name}
        onKeyPress={(e) => this.handleKeyPress(e)}
        >
        { this.props.label}
      </button>
    );
  }
}
```
 Comment 10: @danm am I wrong to thing that what you are talking about already exists in `implements` syntax [Interface Type](https://flow.org/en/docs/types/interfaces/)?

What I want to know is what this error means — could somebody @flowtype of @facebook team comment on why class property declarations are covariant by default? What are we protecting except the obvious situation when I call `this.thing()` but it not that `thing()` anymore?
 Comment 11: This is not a solution per se but it may be better way to use function binding (feel free to correct me):
```jsx
<SomeInput onChange={this.handleChange.bind(this)} />
```
 Comment 12: @ermik you don't want to do that, because then `SomeInput` gets a different, `!==` reference on every render. That needs to be bound in the constructor and stored on the instance to avoid this rendering performance footgun.
 Comment 13: Maybe you could finally add an option to disable certain *rules*, not *lines* from e.g. `.flowconfig` file? This particular error by flow does not contribute in any way to make code better. Even worse it makes you a) spend time to figure out why there is an error 2) how to "fix" what is not really broken 3) write more unnecessary code. 

Adding `(this: any).onClick = this.onClick.bind(this);` just because flow.js wants it to be that way is not a good practice.
 Comment 14: @ljharb there's a warning I did not see previously. I've amended my comment.
 Comment 15: @ermik that has the identical risk. It *must* and *only* be constructor-bound to avoid this footgun (or bound in a clsss field)
 Comment 16: Agreed. Don't bind in render methods :)
 Comment 17: It is unnecessary to bind this to your method in the `constructor` when calling to the event handler using an arrow function like this:
```javascript
(e) => this.handleKeyPress(e)
```
The `this` value inside the arrow function is taken from the enclosing lexical context

Example:
```
// @flow
import React from 'react';

type MyComponentPropsType = { show: boolean};
type MyComponentStateType = {|
  show: boolean
|};

class MyComponent extends React.Component<MyComponentPropsType, MyComponentStateType> {
  props: MyComponentPropsType;
  state: MyComponentStateType;
  handleToggle: (event: any) => void;

  constructor(props: MyComponentPropsType) {
    super(props);
    this.state = { show: this.props.show };
  }

  handleToggle(event: any) {
    // Do something with the event
    // ....
    this.setState(state => ({
      show: !state.show
    }));
  }

  render() {
    return (
      <button type="button" onClick={(e) => this.handleToggle(e)} >
        <span> {this.state.show ? 'Hide' : 'Show'} </span>
      </button>
    );
  }
}

export default MyComponent;
```

 Comment 18: @joselcc that has a performance impact, as now the function is repeated N times instead of being shared on the prototype. The only good solution is a constructor-hound instance method - never put arrow functions in class fields.
 Comment 19: Does binding your method in the constructor share the method to the prototype?

Sent from my iPhone

> On 23 Nov 2018, at 15:01, Jordan Harband <omoody@example.net> wrote:
> 
> @joselcc that has a performance impact, as now the function is repeated N times instead of being shared on the prototype. The only good solution is a constructor-hound instance method - never put arrow functions in class fields.
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or mute the thread.

 Comment 20: As this is a pretty common pattern, it would be great to see some progress on this. I would argue that it both clutters the code to annotate every method that needs to be bound, as well as it is hard to enforce in a large code base.

 What about adding a configuration option to disable this rule? 
 Comment 21: I guess if you use hooks, you can avoid classes and don't need to worry about it any more?
 Comment 22: We're on react-native, which just recently got hooks. And certainly, while new code would use hooks where applicable, there is still a large legacy code base with classes which will live on for a long time 😞  
 Comment 23: ```javascript
(this: any).funName
```
is given me a `Unexpected token :Flow(ParseError)`. Does anyone knows what to do?
Thanks
 Comment 24: @ThiagoMiranda ,
use this way
```js
constructor(props) {
    super(props);
    this.handleClick = this.handleClick.bind(this);
}

/*38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5 handleClick: () => void */
handleClick(event /*: SyntheticEvent<HTMLInputElement> */) {
    // ... something something
}
```
as @warpr mentioned above.
 Comment 25: The best solution i've found so far:

````javascript
import { boundMethod } from 'autobind-decorator';

class MyClass extends Component<void> {
  /* no constrcutor needed */

  @boundMethod
  handleClick( e ) {
     /* */
  }
}
````

See https://github.com/andreypopp/autobind-decorator#readme for details.
 Comment 26: The best solution i've found so far:

````javascript
import { boundMethod } from 'autobind-decorator';

class MyClass extends Component<void> {
  /* no constrcutor needed */

  @boundMethod
  handleClick( e ) {
     /* */
  }
}
````

See https://github.com/andreypopp/autobind-decorator#readme for details.

Be aware that you need to disable annotation warnings in .flowconfig (esproposal.decorators=ignore) and provide stub for autobind-decorator in flow-typed directory.
{'source': 'GithubIssues', 'repo_name_with_owner': 'facebook/flow', 'issue_id': 300252233, 'repo_stars': 24184.0}