…l consequents

Disclaimer: This commit description was generated by an LLM (Claude).

With the `flow` plugin, the params of an arrow at the start of a conditional consequent are not converted to patterns when the arrow is parsed, so that `a ? (b): c => d` can be disambiguated afterwards in `parseConditional`. `getArrowLikeExpressions` then converts them, but it skipped arrows with a block body entirely. As a result:

- The params of a block-bodied arrow in that position stayed as expressions: `ObjectExpression`, `ArrayExpression`, `AssignmentExpression` and `TypeCastExpression`, and `SpreadElement` for async arrows. For example, in `a ? async ({ b }) => {} : c` the param is an `ObjectExpression`. The params were also never validated, so `a ? ({ b, b }) => {} : c` and `a ? async (...b = 1) => {} : c` parsed without errors, while `a ? ({ b, b }) => b : c` throws `Argument name clash`.
- A block-bodied arrow with a return type was never considered for re-parsing, so `a ? (b) : c => {};` threw `Unexpected token, expected ":"`, although `a ? (b) : c => d;` parses as `a ? b : (c => d)`.

This is a regression from babel#16425, first released in 7.24.5: it added the `node.body.type !== "BlockStatement"` condition to narrow `node.body` for `stack.push(node.body)`, which also stopped block-bodied arrows from being validated or collected. 7.24.4 handles all of the cases above.

Block-bodied arrows are now validated, or collected as possibly ambiguous, in the same way as arrows with an expression body. Only the traversal into the body is still limited to expression bodies, since a block body can't contain the conditional's `:`.

Found via react/metro#1725, where the `SpreadElement` param crashed a downstream Babel plugin.

Tests: added `flow/arrows-in-ternaries/block-body-params`, `flow/arrows-in-ternaries/block-body-invalid-params` and `flow/arrows-in-ternaries/block-body-return-type-like`. `yarn jest packages/babel-parser` and `yarn jest flow` pass, with and without `BABEL_8_BREAKING=true`.