Align function parameters with their types

# Summary

I'd like to propose a way to make function declarations more readable, especially functions that take more than one or two arguments. Consider this declaration from the core `List` module:

```
foldl : (a -> b -> b) -> b -> List a -> b
foldl func acc list =
```

At a glace, it's a bit tricky to see how the types in the signature -- which contains five arrows -- line up with the arguments (only three of them) in the definition. To make this easier, I propose to align the arguments under their types, like so:

```
foldl : (a -> b -> b) -> b -> List a -> b
foldl func acc list =
```

# Discussion
## Rule
Roughly, the rule is to align the first character of each type with the first character of the corresponding argument, by padding whichever one is shorter. The `=` lines up under the `-` of the last `->`. Or more generally for higher-order functions, the `=` lines up under the `-` of the `->` after the last declared argument. In the special case of a function with no arguments, the `=` lines up under the `:`.

Destructuring in the arguments should follow similar rules in something of a recursive fashion. I realize there's some hand-waving here though. :) For example:

```
foo : (Int , String) -> String
foo (limit, s) =
```

## Pros and Cons
This lets you answer the questions like "what's the type of the `list` argument?" or "what's the name of the argument of type `b`?" by simply looking directly above or below. And it lets you answer the question "what's the return type of this function?" by scanning right for the `=` and then looking up.

The main con I can think of is that this will generally increase the length of function declaration lines.

## Variants
I think some minor debates could be had, including: Do we align with parens or with the types within the parens?

```
foldl : (a -> b -> b) -> b -> List a -> b
foldl func acc list =
```

Do we push the `->` out beyond the name of long arguments? (In other words, require that `->` always have blank space beneath it?)

```
foldl : (a -> b -> b) -> b -> List a -> b
foldl func acc list =
```

# Examples
For more examples, I've formatted all of the type signatures from `List` using this scheme:

```
singleton : a -> List a
singleton value =

repeat : Int -> a -> List a
repeat n value =

range : Int -> Int -> List Int
range lo hi =

cons : a -> List a -> List a
cons =

map : (a -> b) -> List a -> List b
map f xs =

foldl : (a -> b -> b) -> b -> List a -> b
foldl func acc list =

foldr : (a -> b -> b) -> b -> List a -> b
foldr fn acc ls =

filter : (a -> Bool) -> List a -> List a
filter isGood list =

length : List a -> Int
length xs =

reverse : List a -> List a
reverse list =

member : a -> List a -> Bool
member x xs =

all : (a -> Bool) -> List a -> Bool
all isOkay list =

any : (a -> Bool) -> List a -> Bool
any isOkay list =

maximum : List comparable -> Maybe comparable
maximum list =

minimum : List comparable -> Maybe comparable
minimum list =

sum : List number -> number
sum numbers =

product : List number -> number
product numbers =

append : List a -> List a -> List a
append xs ys =

concat : List (List a) -> List a
concat lists =

intersperse : a -> List a -> List a
intersperse sep xs =

sort : List comparable -> List comparable
sort xs =

head : List a -> Maybe a
head list =

tail : List a -> Maybe (List a)
tail list =

take : Int -> List a -> List a
take n list =

drop : Int -> List a -> List a
drop n list =

partition : (a -> Bool) -> List a -> (List a, List a)
partition pred list =

unzip : List (a,b) -> (List a, List b)
unzip pairs =
```

The issue names no files, tests, or entry points; begin by locating the formatter logic for Elm function declarations. Resolve the alignment rules and variants described in the discussion, then verify that representative examples such as List signatures are formatted consistently.

Written by the indexing model from the issue text.