Inconsistent type passed through in fallback path of `vec_ptype2()`

[DavisVaughan]

Right here, notice how we pass in x_type. I think that is a typo, it should be y_type:

vctrs/src/ptype2.c

Line 71 in 29c5518

return vec_ptype_or_s3_fallback(y, p_y_arg, x_type, call, s3_fallback);

That results in this weird first result

vec_ptype_common_fallback(NULL, foobar(1))
#> numeric(0)
#> attr(,"class")
#> [1] "vctrs_foobar"

vec_ptype_common_fallback(foobar(1), NULL)
#> numeric(0)
#> attr(,"class")
#> [1] "vctrs:::common_class_fallback"
#> attr(,"fallback_class")
#> [1] "vctrs_foobar"

vec_ptype_common_fallback(unspecified(1), foobar(1))
#> numeric(0)
#> attr(,"class")
#> [1] "vctrs:::common_class_fallback"
#> attr(,"fallback_class")
#> [1] "vctrs_foobar"

vec_ptype_common_fallback(foobar(1), unspecified(1))
#> numeric(0)
#> attr(,"class")
#> [1] "vctrs:::common_class_fallback"
#> attr(,"fallback_class")
#> [1] "vctrs_foobar"

But if we change it to y_type, a whole bunch of tests break with snapshot diffs that look like

    Error in `list_combine()`:
-   ! Can't combine `x[[1]]` <vctrs_foobar> and `x[[2]]` <double>.
+   ! Can't combine `x[[1]]` <vctrs:::common_class_fallback> and `x[[2]]` <double>.

but I think what is happening here is that we never had good support for unwrapping the fallback object in our error messages, see #1981