I'm merging this because this will effectively end discussions about when to use { ... } and do ... end. Thank you!!

While working on rufo I realized this is wrong.

For example:

foo bar {
  1 + 2
}

Here the block is associated with bar, but converting it to do/end will associate it to foo, which changes the semantic of the program. I'm reverting this.

@asterite I don't think that do/end should have different parsing rules to {}, I should be able to switch between the two freely. I'd even suggest going further and ensuring that you need braces around calls with do/end/braces so that you'd need to do

foo(bar) do
  1 + 2
end

but either of those suggestions can be implemented without the other.

I think it's the fact this changes semantics which should be fixed, not this PR (but reverting it is good temporarily).

I've looked into making a PR for my above suggestion but I'm finding it hard. The crystal parser is very complex and has a lot of accumulated, undocumented state and undocumented abstractions. It's very hard to refactor the parser to take advantage of the added simplicity of having 1 unambiguous parsing rule for blocks.

Perhaps @asterite would have fun unifying the two block syntaxes :). I still think it's a bad idea that do/end and {/} have slightly different semantics, regardless of formatter changes. Ensuring braces around the arguments of functions with blocks seems like a good way to handle this breaking change such that it's always an error when it's an issue.