This commit enables a combination of two language features that dovetail
nicely together (as remarked by @StefanKarpinski in [1]): for/else and
break-with-value, which together allow something like:

    name = for person in people
        if person.id == id
            break person.name
        end
    else
        generate_name()
    end

The parsing patch is pretty straightforward. As for the code lowering
part, I opted to make a second version of `'break-block`, called
`'break-block-with-value`, which passes a target variable for the return
value onto the `break-labels` stack. That's where the `'break` operation
finds it.

An alternative approach would be something more similar to the existing
`replace-return` function: Instead of having an intermediate node
representing `'break-block-with-value`,we could traverse the expression
tree and replace `break-with-value` by an assignment followed by a
break.

I have no opinion either way; the current commit seemed like the obvious
implementation to me, but that was before I saw `replace-return`'s prior
art.

This patch still has a few places marked `TODO`, where scoping issues
for the `else` block need to be resolved. I'll tackle that after
awaiting feedback.

[1] JuliaLang#22891

Because a new language feature should probably be used in
the standard library, to encourage cargo-culting.

Before 976ff84, a parsed `break` expression `'(break)` was being
augmented to `'(break <label>)` by the function `expand-forms`. Since
the latter is supposed to be idempotent [1], it used to check

    (pair? e)

before deciding on replacing it. In 976ff84 however, the parsed
break can have a value expression, so `(pair? e)` can be true for that
reason as well. Thinking I was being smart, I replaced the check by

    (symbol? (cadr e))

not realizing that a lone symbol can be a valid expression too!

This commit fixes that by *always* compiling the break expression to a
*triple*

    '(break <expression> <label>)

where <expression> may be `'(null)`. This should have no big
implications for the code being generated, because `'(null)` generates
no code when, in the function `compile`, `(and value tail)` is false,
which is likely the typical case.

[1] At least, that's what I'm guessing is the reason.

…ck and break-block-with-value

Instead, we give every `break-block` an `else`-block, potentially equal
to `'(null)`. This gives us one less atom to worry about.

This commit also makes a small modification to `compile`, which now
passes the value of `tail` for a `break` onto the `break-labels` stack.
That means a `break` can be compiled to a `return` if the `break-block`
is in the last position of a function.

The following issue:

    Test Failed
      Expression: Base.incomplete_tag(parse(str, raise=false)) == tag
       Evaluated: none == block

was due to returning a different error message string in case of parsing
the incomplete string "for i=1;". This commit fixes it by delegating
error handling to `expect-end`.

This was triggered by

    Error in testset inference:
    Test Failed
      Expression: all(isleaftype, (ast12474[1])[1].slottypes)

which had, as a root cause, the unused new-mutable-var being of type
Any.

Now, that isn't really what this doctest is trying to avoid, but I'm
guessing it's worthwhile avoiding an unneeded mutable var nonetheless.

This is an artifact from when I wasn't sure whether anything else would
write to the break-labels stack apart from the code point that I had
updated. I'm now confident that doesn't happen, so no need for special
cases.

I postponed this mostly because the names of the methods sounded scary
and I thought I'd need to think about it; turns out it's just a tree
traversal.

(Use `git blame -w` to see the most recent functional changes to this code.)

…rser level

Since 8a8d4cc, julia-syntax.scm can deal with length 1
'break' expression nodes. So there is no need for this. In addition,
this ensures that :(break) prints as :(break), not as

    :($(Expr(:break, nothing)))

This was caught by a testcase in test/show.jl

This was only used for testing the for/else construct; it's not actually
more readable. As discussed in JuliaLang#23260, `intersect()` is a nicer show
case. Moreover, this prevents a merge conflict with `master`, which has
diverged significantly by now.

This reverts commit d8b2553.

This fixes conflicts introduced by JuliaLang#24075 and JuliaLang#22659.

Just keeping this branch up-to-date to prevent bitrot.

Fixes merge conflicts caused by 0fffb36.

This fixes merge conflicts introduced by 62fbad2 and 3a0c6e2.
neither conflict was fundamental or complicated to solve.

This updates this branch to current master by merging it
and by fixing the merge conflicts introduced by 57b46e7.

I don't fully understand the functionality of that commit and
though the fixes I did result in no compilation errors
and in working `make test-core` (where this branch introduces
tests), it may make sense to double-check interactions
between exceptions and break-with-value before merging this.