allow more whitespace inconsistencies in case statements

Elm itself requires the following of `case` branches:
- all branches have the same indentation
- the indentation of branches is greater than the indentation of `case`

Ideally, elm-format should relax both of those requirements as much as possible (while maintaining good parsing performance for already-formatted code, and having decent parser performance for lenient code), allowing:

```elm
f x =
case x of
_ -> ()
_ -> {- different indentation -} ()
```

```elm
f x =
case x of
_ -> {- indentation less than `case` -} ()
```

This one might be harder to do safely (performantly), as "fresh lines" (newline with no trailing whitespace) are handled specially when parsing whitespace:
```elm
f x =
case x of
_ -> {- branch starts after a fresh line -} ()
```

## Ambiguity

When case statements are nested, relaxing these rules can result in ambiguity.

```elm
f x =
case x of
Just y ->
case y of
_ -> ()
_ -> {- which case is this attached to? -} ()
```

```elm
f x =
case x of
Just y ->
case y of
_ -> ()
_ -> {- which case is this attached to? -} ()
```

```elm
f x =
case x of
Just y -> case y of
_ -> ()
_ -> {- which case is this attached to? -} ()
```

```elm
f x =
case x of
Just y -> case y of
_ -> ()
_ -> {- which case is this attached to? -} ()
```

... other examples?

## Open questions

- [ ] are there other possible parser ambiguities that could result from relaxing these rules?
- other syntax that uses `->`
- [ ] lambda functions
- [ ] how does this interact with other whitespace-sensitive syntax?
- [ ] `let` expressions
- things that response to "fresh lines"
- [ ] top-level definitions

Start by investigating the parser's whitespace handling for case branches and the special treatment of fresh lines described in the issue. Resolve the listed nested-case and arrow ambiguities, then verify that the examples are accepted without harming performance on already-formatted or lenient code.

Written by the indexing model from the issue text.