textDocument/rangeFormatting always hangs?

Nobody has claimed this yet.

reason-language-server hangs for me when sending it the following textDocument/rangeFormatting request (I gave it 60 seconds):
```
{
"textDocument": {
"uri": "file:///home/me/dev/node-scratch/my-new-project/src/Baz.re"
},
"options": {
"tabSize": 2,
"insertSpaces": true
},
"range": {
"start": {
"line": 2,
"character": 0
},
"end": {
"line": 2,
"character": 16
}
}
}
```
`Baz.re` looks like this:
```
let foo = "Bar";
let bar = 231;
```

emacs lsp-mode.el (lsp-mode-20200311.612) seems to send this request whenever I paste a line of text into the file I'm editing (for example, if I paste in `let foo = "Bar";` again so that I have two lines in a row like that). I checked the logs for vscode when pasting text, and VS Code does not seem to do that -- in fact I wasn't able to trigger it to send a textDocument/rangeFormatting at all.

So I have a suspicion that most of the editor LSP clients for Reason use the node.js implementation (all of which are implemented using the same node module I think) and never use that method, and that reason-language-server may never respond properly to requests of that method, always hanging?

If I hack `lsp-mode.el` to prevent it from trying, at least basics work -- in `reason-mode` with lsp enabled and using reason-language-server, syntax highlighting and tooltips (`lsp-ui-mode`) work and I can get type info using `lsp-describe-thing-at-point`. So perhaps one possible fix is to remove support for that method? (guessing totally here, I know nothing about LSP nor Reason)

Start by reproducing the textDocument/rangeFormatting request against the two-line Baz.re example and inspect the request handling in reason-language-server. Compare the behavior with emacs lsp-mode.el and the VS Code logs; done means the request receives a response instead of hanging, or its unsupported behavior is clearly defined.

Written by the indexing model from the issue text.