Don’t share TARGs between recursive ops

Don’t share TARGs between recursive ops

I had to change the definition of IS_PADCONST to account for the
SVf_IsCOW flag.  Previously, anything marked READONLY would be consid-
ered a pad constant, to be shared by pads of different recursion lev-
els.  Some of those READONLY things were not actually read-only, as
they were copy-on-write scalars, which are never read-only.  So I
changed the definition of IS_PADCONST in e3918bb703c to accept COWs
as well as read-only scalars, since I was removing the READONLY flag
from COWs.

With the new copy-on-write scheme, it is easy for a TARG to turn into
a COW.  If that happens and then the same subroutine calls itself
recursively for the first time after that, pad_push will see that this
is a pad ‘constant’ and allow the next recursion level to share it.

If pp_concat calls itself recursively, the recursive call can modify
the scalar the outer call is in the middle of using, causing the
return value to be doubled up (‘tmptmp’) in the test case added here.

Since pad constants are marked PADTMP (I would like to change that
eventually), there is no way to distinguish them from TARGs when the
are COWs, except for the fact that pad constants that are COWs are
always shared hash keys (SvLEN==0).