Allow \(&sub) for & proto

I accidentally broke this in e41e9865.  Prior to this commit,
\&foo was becoming srefgen and \(&foo) was becoming refgen.
Srefgen is a slightly faster version of refgen that only han-
dles one item.  The easiest fix was to change the logic
in op.c:ck_spair so that \(&sub) with parens becomes srefgen.
[perl #47363] \@ proto and parenthesised arrays

The bug reported was that foo((@foo)) and foo+(@foo) pass a scalar
reference to a subroutine with a \@ prototype.

The scalar reference passed is the last element of @foo, or
&PL_sv_undef if @foo has no elements.  If the containing sub is called
in list context, however, the entire array is flattened and the proto-
typed sub gets a list of references longer that it is expecting.

$ ./perl -Ilib -e 'sub f ($\@) { warn "@_"; warn ${$_[1]} if ref $_[1] eq SCALAR } @_ = a..z; f(1, @_); f(1, (@_))'
1 ARRAY(0x7fe1220061f0) at -e line 1.
1 SCALAR(0x7fe1220353e0) at -e line 1.
z at -e line 1.
$ ./perl -Ilib -e '() = sub {sub f ($\@) { warn "@_"; warn ${$_[1]} if ref $_[1] eq SCALAR } @_ = a..z; f(1, @_); f(1, (@_)) }->()'
1 ARRAY(0x7f914a8362a8) at -e line 1.
1 SCALAR(0x7f914a806430) SCALAR(0x7f914a82f678) SCALAR(0x7f914a82f690) SCALAR(0x7f914a82f6c0) SCALAR(0x7f914a82f6a8) SCALAR(0x7f914a82f750) SCALAR(0x7f914a82f768) SCALAR(0x7f914a82f7f8) SCALAR(0x7f914a82f810) SCALAR(0x7f914a82f7e0) SCALAR(0x7f914a835cf0) SCALAR(0x7f914a835d08) SCALAR(0x7f914a835d20) SCALAR(0x7f914a835d38) SCALAR(0x7f914a835d50) SCALAR(0x7f914a835d68) SCALAR(0x7f914a835d80) SCALAR(0x7f914a835d98) SCALAR(0x7f914a835db0) SCALAR(0x7f914a835dc8) SCALAR(0x7f914a835de0) SCALAR(0x7f914a835df8) SCALAR(0x7f914a835e10) SCALAR(0x7f914a835e28) SCALAR(0x7f914a835e40) SCALAR(0x7f914a835e58) at -e line 1.
a at -e line 1.

The problem here is that \ applied to an array usually checks whether
the array was parenthesized.  If it was, it gets flattened.  The same
code paths were used for the implicit \ added by the prototype.  The
reason for the erratic behaviour based on the context of the enclos-
ing sub is that the refgen op had no context applied to it.  Usually
that means an op is at the end of a sub and should inherit the call-
ing context.

If we change the logic to remove the parentheses from the array before
applying the implicit \ then it behaves as expected.  Furthermore, we
end up with a srefgen op, which doesn‘t care about context, so we
don’t need to bother setting it.