review of can_group factorization by @gasche:

> I reviewed the change to `can_group` and believe it is correct.
> (I knew it would be nicer as a binary operation!)
>
> The different treatments of Lazy and Tuple/Record does look a bit odd,
> but I believe that it is actually the right thing to write.
>
> In the Tuple or Record case, the idea is that we can group Any heads
> with the Tuple/Record case and just explode all of them (including the
> Any cases) according to the tuple/record arity.
>
> In the Lazy case, the corresponding choice would be to add Any values
> to the Lazy group, and force all the elements of the group. This is
> not so nice, because intuitively we shouldn't force Lazy values unless
> we have to.
>
> One may expect that in general the argument of the pattern will be
> forced anyway, as long as there is at least one Lazy pattern above in
> the matrix, so it doesn't really matter whether we include the Any
> patterns in the forced group or not. I would argue that (1) even if
> that was true, it would be semantically dubious to handle Any that way
> (see a more precise criterion below), (2) I am not actually sure that
> this is true, what if the first group gets found unreachable by
> splits in following columns?
>
>     # type void = | ;;
>     # match (lazy (print_endline "foo"), (None : void option)) with
>       | lazy (), Some _ -> .
>       | _, None -> false;;
>     - : bool = false
>
> This gives the following decision tree for whether Any is included in
> the group:
>
> - Can the absence of Any be used to generate nice/efficient tests for
>   the heads of the group? In that case, don't include Any.
>   (Not included: all the Constant cases, Array (discriminate on size),
>    String, etc.)
>
> - Is Any always exactly equivalent to a more-defined head for values
>   of this type? In that case, do include Any, otherwise do not.
>   (Included: Variant, Record)
>   (Not included: Lazy)