Crystal: Continue with anonymous block arguments

[straight-shoota]

Follows up on #8117. This PR added syntax for anonymous block arguments def foo(&). The idea is to use this syntax exclusively for yielding methods.
Currently it's valid to completely omit the block argument when there's yield in the body. This hides the yielding nature of the method from the signature and API docs. Such an essential property should be made visible.

After the initial syntax was added, we switched usage in stdlib in #8394.

The next step would be to deprecate some of the currently valid method signatures. The idea as proposed in #8117:

• Just & means a non-captured block argument: because it doesn't have a name there's no way to capture it
• &block means a captured block argument, and the compiler will verify that it's used in the semantic phase (because it might be mentioned inside a macro)
• &block without a mention will give a compile error suggesting to either change it to & to avoid a closure or to mention it somehow
• if you yield and the method signature doesn't have & the compiler will tell you

This would be a breaking change for yielding methods with a named block argument or no block argument at all, and also for methods with a named block argument that's never used in the literal scope of its body. But it improves clarity and helps to better identify the behaviour of block arguments.

Part of #7157

[RX14]

This hides the yielding nature of the method from the signature and API docs.

No, it shows up in the API docs if you use yield. We shouldn't force people to annotate their method with an unneccesary & if they use yield but don't want to annotate the arg types. The rest of the changes are great.

[straight-shoota]

Oh my bad. The API docs already represent this correctly.

I'd still prefer always specifying & on yielding methods (types can be omitted obviously). Even if it's technically unnecessary, it still improves readability of the source code. We already put & in the signature in the API docs, but reading code is almost as important.
I acknowledge that this doesn't need to be enforced by the compiler, though. It could just be a style guide. Maybe consider it for the formatter?